Path: utzoo!attcan!uunet!clyde.concordia.ca!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!uniwa!bilby.cs.uwa.oz.au!bison!jamesp From: jamesp@bilby.cs.uwa.oz.au (James Pinakis) Newsgroups: comp.protocols.tcp-ip Subject: Re: Reliable Datagram ??? Protocols Message-ID: Date: 24 Oct 90 05:54:42 GMT References: <9010231728.AA03948@braden.isi.edu> Organization: Dept. Computer Science, University of Western Australia. Lines: 24 Maybe I've missed something here, but what happens if you have multiple entities which want to send datagrams between each other, and it may be the case that only one datagram is sent between any given pair. In this case, isn't the overhead of establishing a TCP connection merely to send one "datagram" (or "data which preserves message boundaries" or whatever the pedants like to call it) too great? Isn't this the exact situation when a different protocol is required and building a scheme on top of TCP is bad? And if I don't _want_ a connection between two sites (i.e. I only want to send discrete messages) then why should I create one, send the data, and then pull it down? I agree that such a protocol is not really connectionless and that state must be maintained at both ends, but at least from the application layer (assuming it's implemented as a transport layer protocol) it _looks_ like I am reliably sending datagrams. I've spend some time over the last few months implementing just such a protocol. Basically it is a fairly straightforward implementation of a sliding window protocol (protocol 6 from Tanenbaum actually) optimised to support a particular sort of client/server model. The main thing which it has over TCP, I believe, is that establishing the state information is sufficiently "lightweight" so that the cost of a client sending a small number of packets to a server is not prohibitive. james jamesp@bison.cs.uwa.oz.au