[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: "Binary XML" proposals
"Al B. Snell" wrote: > > On Thu, 12 Apr 2001, Vassilis Papadimos wrote: > > > > Three-way handshake before you even send the request, the > > > connection teardown? *retch*! > > > > The three-way handshake is part of any TCP-based protocol, right? > > Yep > > > Plus, with HTTP versions > 1.1, you can amortize the connection > > overhead over multiple connections. > > Mmmm, but who implements this in practice? Some Web clients are starting > to, but which SOAP clients/servers? > > And there are big problems with that model, too. You can't do asynch > RPCs. You do send, wait, reply, send, wait, reply. You need to start > opening more connections if you want to issue parallel requests. > > > Are there any reasonable alternatives? > > Sure; UDP. Look at existing RPC protocols and learn from them. > > ONC RPC allows UDP and TCP transports. > > The UDP one has a maximum message size, 64k, and doesn't guarantee > delivery (so you have to retransmit manually; I wish it'd automate it!) A) UDP has no mechanism for handling fragments, so it's maximally 1500 because of Ethernet and less if someone decides to lower the MTU. The server may be able to unfragment, but it's not clear to me how this would work. B) With UDP, you are limited to a single thread or process that actually recieves the packets on a particular IP address port combination. C) Because you don't have the session guaruntees that TCP sequence numbers or an encryption layer give you, you have to waste an already small payload with repeated authentication information to avoid spoofing. D) Generally each message is a UDP packet which is highly wasteful of network/router/server resources. You could implement something like TCP over UDP, but that's only really needed, usually, for streaming applications. > The TCP one is good if you expect a long conversation, and don't mind the > conversation being synchronous. There is no reason that TCP implies synchronous. That's just the naive, old fashioned, and generally inappropriate implementation. TCP is perfect for a full async message oriented system. In fact Imap is a good example of this, I believe. I have had a lot of experience at several companies using async messages over TCP as far back as 1986. It appears to have been known in the mainframe world for a very long time. > Eg, the RPC protocol for NIS (aka YP) recommends that you use UDP for just > asking simple questions of the NIS database (it works like LDAP or DNS as > a first approximation), but if you're a backup server wishing to take a > database replica, consider opening a TCP connection and using that. > > Read RFCs - http://RFC.net/rfc998.html would be nice if it was widely > implemented. > > http://RFC.net/search.php3?phrase=RPC > > > > > Vassilis. > > > > ABS > > -- > Alaric B. Snell > http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/ > Any sufficiently advanced technology can be emulated in software sdw -- sdw@l... http://sdw.st Stephen D. Williams 43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax Dec2000
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|