jamesp@wacsvax.OZ (James Pinakis) (12/20/89)
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
koreth@panarthea.ebay.sun.com (Steven Grimm) (12/21/89)
In article <1486@wacsvax.OZ> jamesp@wacsvax.uwa.oz.OZ (James Pinakis) writes: >Would I be better off sticking with tcp-ip and >accepting a limit to the number of client processes? Here's a little trick you can use to increase that limit to a fairly outrageous value. This does increase your server's complexity, possibly by a great deal depending on exactly what you're doing. (This is BSD UNIX-oriented.) Figure out how many open file descriptors your process can have. The getdtablesize() call should do it. Serve as usual until you hit the limit. Then fork. If you like, make a pipe or socket connection between the parent and child process (this may be necessary for your application.) Then close the listen()ing file descriptor in the parent process; in the child, close all the connected descriptors. The child will now accept new connections. If everyone disconnects from a parent process, it should die as it's no longer needed. If everyone disconnects from a process in the middle of a chain, that process needs to stick around as UNIX provides no way to stick two pipes/sockets together. Hope that helps. It may be more trouble than it's worth for your application, but it's a worthwhile method for some things. --- " !" - Marcel Marceau Steven Grimm Moderator, comp.{sources,binaries}.atari.st koreth@ebay.sun.com ...!sun!ebay!koreth
mak@hymir.cs.cornell.edu (Mesaac Makpangou) (12/23/89)
In article <1486@wacsvax.OZ> jamesp@wacsvax.uwa.oz.OZ (James Pinakis) writes: > 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 implemented almost such a transport protocol at INRIA (France) for the SOS communication service. (SOS is an object-oriented distributed operating system developped at INRIA by the SOR group.) To summarize, the SOS communication service is made of four layers: 1) The network interface layer. 2) The transport layer. 3) The protocol objects layer. 4) The application interface layer. In the transport layer, I implementrd a reliable unicast and multicast datagram transport protocol. The difference with what you want, is that this protocol doesn't enforce the delivery in sequence of messages exchanged between protocol objects. There are a lot of reasons of doing so. The main one is that, not all application protocols (here encapsulated by what we call protocol objects) need this functionnality. So we made the choice to provide such functionality at a higher level (i.e at the protocol object layer). The protocol objects which want to enforce the sequencing implement it by queueing messages arriving in an incorrect order, and just waiting the arrival of the appropriate message. > I'm currently implementing a sliding window protocol (Tanenbaum's > protocol 6, actually) but this is getting nastily complicated. To do this, I used some kind of sliding window too. The main point is that I have a very large window. I managed to accept messages even if they were not in sequence, but I ensure that every message is delivered to its destinator(s) (i.e reliable datagram). > 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. In my implementation, I have also a set of protocol state. I think however that its size is reasonable. For my implementation, I assumed that the set of potential clients and servers was known (this was realistic since this was the set of sites runing our system). > Basically, I'm wondering if anyone has experience/source code which > they would like to share with me. I have the code, and an article and my Ph.D dissertation describing this stuff. I will also continue to work on its improvement sometimes by end february 1990. So I will be glad to share my experience and my source with you. > How efficient is this protocol likely to be? As far as the efficiency is concerned, the measures I did year ago, tended to show that my protocol outperforms tcp for messages of size range from 1024 bytes to 1500 bytes. Below 1024 bytes, the tcp was better than my protocol. The best explanation I have is that, UDP sends one packet for every user message. I did not look closely to the tcp code, but I suspect that small user messages could be sent in a single inter-sites message. For messages bigger than 1500 bytes, I did no measures since my implementation assumes a maximum size of 1500 for all transport packet (the fragmentation is implemented by the protocol object level). > Would I be better off sticking with tcp-ip and > accepting a limit to the number of client processes? At the end of my implementation, I asked myself if it was really necessary to do this, instead of using tcp. I provide some answers in my thesis. To summarize, I think that it is suitable for an operating system to allow each application (or more precisely each application protocol) to pay only for what it really needs. I'm convince that enforcing the sequence (more generally the delivery order: causal ordering, atomic ordering, fifo ordering, etc.), and enforcing the fragmentation/reassemblage for examples, are not needed by all application protocols. These functionalities should be better implemented by appropriate protocol objects. So, in my case, I still believe it was necessary. In your case however, it seems to me that your choice should be guided by the importance of the limitation of the number of client processes in your system. References: ----------- 1) Protocoles de communication et Programmation par Objets: l'exemple de SOS. (Ph.D Thesis, Universite' Paris 6, France. February 1989. Available as Rapport de Recherche INRIA.) This dissertation discusses extensively the structure and the implementation of the SOS communication service. Chapter 4 describes the implemtation of our reliable datagram protocol. Chapter 8 discusses the performance figure of this protocol and compares it with tcp and udp. 2) The SOS Object-Oriented Communication Service (In procedings of ICCC89 Tel Aviv (Israel), October-November 89.) I will be happy to send you a copy of both. Also, the code is in C++, and I will check how we can share this code once I go back at INRIA sometimes in February. Mesaac
bdr@IFS.UMICH.EDU (01/02/90)
I am also very interested in this question. Could you forward the response to me ? Thanks, Bob Riddle IFS Project University of Michigan