Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!uniwa!wacsvax!jamesp From: jamesp@wacsvax.OZ (James Pinakis) Newsgroups: comp.protocols.tcp-ip Subject: Building a reliable datagram protocol on top of UDP Message-ID: <1486@wacsvax.OZ> Date: 20 Dec 89 05:24:05 GMT Reply-To: jamesp@wacsvax.uwa.oz.OZ (James Pinakis) Organization: Comp Sci, University of Western Australia Lines: 35 This may have been done to death previously but I can't find out anything about it so here goes... I'm trying to write a protocol which delivers variable size packets reliably (i.e. in sequence, no dups, no dropped packets) using the Internet UDP. I opted to use UDP since I wanted a single (server) process to be able to accept messages from any number of sites (clients), rather than (using the tcp-ip client/server model) a process having to accept a connection, then fork a process to talk on that connection. I would also prefer to only have one socket to listen on, rather than a pile of file descriptors to select on (since the number of clients is potentially large). I'm currently implementing a sliding window protocol (Tanenbaum's protocol 6, actually) but this is getting nastily complicated. It amounts to having to maintain a set of protocol state information for every client which establishes a "connection" to the server. This implies a reasonably large setting up operation every time a new client wants to start talking with the server. Basically, I'm wondering if anyone has experience/source code which they would like to share with me. How efficient is this protocol likely to be? Would I be better off sticking with tcp-ip and accepting a limit to the number of client processes? Thanks in advance james -- Department of Computer Science, ACSnet: jamesp@wacsvax.oz University of Western Australia, ARPA: jamesp%wacsvax.oz@uunet.uu.net Nedlands WA 6009, UUCP: ..!uunet!munnari!wacsvax!jamesp AUSTRALIA PHONE: (09) 380 2305 OVERSEAS: +61 9 380 2305