Cart
[Home] [By Thread] [By Date] [Recent Entries]
"Al B. Snell" wrote: > > On Fri, 13 Apr 2001, Stephen D. Williams wrote: ... > > B) With UDP, you are limited to a single thread or process that actually > > recieves the packets on a particular IP address port combination. > > Same with TCP. The usual design choices apply; maintain a child pool which > the parent fires requests off to or if the RPC is a very fast operation or > you are lazy, just handle it in a single threaded loop. No, the difference is that after connection, the rest of the session/conversation can be handled by another thread/process/cpu with TCP. You can't do that with UDP since there is no way to know at the kernel/driver level what logical process an incoming UDP packet is bound for. > > 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. > > TCP doesn't provide encryption either, and is not exactly hard to > spoof. You need security on top of TCP too. TCP, with truly random sequence start numbers, can't be spoofed. Once you authenticate a TCP connection, it is far safer to handle further data on the same connection. Because of this, layered encryption is far cheaper since you can assume a certain encryption stream state. Most of what current firewalls do relies on this. Lack of this is why UDP is blocked at nearly all firewalls. > > > D) Generally each message is a UDP packet which is highly wasteful of > > network/router/server resources. > > Why? The same happens with TCP, except there are more headers per > packet. You will only get multiple messages in a packet if they are issued > very fast, since TCP for RPC will usually have the ToS set to request > minimum latency rather than minimum cost. I'm talking about application headers needed to authenticate. Optimized applications and servers will buffer requests in TCP to avoid extra packets and read/writes. > > > > 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. > > ...that HTTP 1.1 will enforce :-) HTTP does allow pipelining... What do you mean? > > > 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. > > TCP can only offer partial asynch operation - the system will delay > packets if one needs to be retransmitted, since it doesn't *know* that the > layer above supports asynch operation. It will force ordering on the > replies, basically - putting effort into doing something that's > undesirable; it's a sledgehammer to crack a nut. Retransmit is only needed in the case of dropped packets which is likely to cause retransmit of fragments somewhere. With enough work queued, the retransmit gets absorbed. The replies are only ordered after they are put into TCP buffers. A true message oriented system will support reordering when requests go to different work queues internally. > > But this debate has been had before amongst the Internet protocols > community... > > RDP and NetBLT are the "correct" solutions, but they're not widely (at > all?) implemented :-( > > > > > sdw > > > > 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
|
