[e2e] t/tcp and web services

[Michael Welzl]

David,

Many thanks for your quick reply! It's just the kind
of answer I was looking for.

As for persistent connections - I agree that they're
a good thing, but in the context of web services, I
guess that they only increase efficency when it comes
to bulk data transmission (result from a web service,
or several parameters containing arrays etc.).

Still, a web service is mainly a RPC - so there is
still quite a reason to worry about the single-shot
requests. Wouldn't a more secure variant of T/TCP
that utilizes cookies (as in SCTP), nonces and
such be worth thinking about? Or is that just
impossible because of T/TCP's very nature?

Another obvious efficiency problem is the fact
that binary data is carried over SOAP over HTTP...
is that being worked on by somebody?

What I would like to see is some sort of "web service
transport protocol". SCTP may be a good match, though...

Best regards,
Michael

On Fri, 2003-12-12 at 08:59, David G. Andersen wrote:
> On Fri, Dec 12, 2003 at 08:22:29AM +0100, Michael Welzl quacked:
> > Dear all,
> > 
> > Here's a question:
> > 
> > Why is RFC 1644 still experimental when Web Services
> > typically run SOAP over HTTP over regular TCP?
> 
> T/TCP has pretty bad and unrectified security problems.
> Or, to quote RFC1644:
> 
> "Security Considerations
>     Security issues are not discussed in this memo. "
> 
> It makes address spoofing attacks worse against some
> services, particularly rsh and the like, and makes it
> easier to DDoS both a server and use servers as DDoS
> amplifiers against chosen victims.  There are circumstances
> in which T/TCP is a nice thing to use, but a publically
> available webserver isn't one of them -- unfortunately,
> since that's what it was really designed for.
> 
> TCP's setup overhead, particularly w.r.t. SOAP and long-running
> sessions over HTTP, are already addressed through the use
> of persistent connections.  T/TCP makes life better for
> single-shot requests, but persistent connections make the
> usual SOAP/etc., cases good enough for people to not worry
> about.
> 
>   -Dave
> 
> > I wonder why this inefficiency isn't bypassed one
> > way or another... I remember that there was a long
> > thread about SOAP's capability of sending binary data
> > in ASCII (*yuck*) approx 2 years ago or so ... but I
> > wonder why nobody seems to do anything about it?
> > 
> > ...or is this taken care of, and I just missed it?
> > 
> > Best regards,
> > Michael
-- 
Michael Welzl <michael.welzl at uibk.ac.at>
University of Innsbruck