Path: utzoo!attcan!uunet!timbuk!cs.umn.edu!ub.d.umn.edu!rutgers!usc!bbn.com!craig From: craig@bbn.com (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: Re: Reliable Datagram ??? Protocols Message-ID: <60365@bbn.BBN.COM> Date: 26 Oct 90 12:06:02 GMT References: <9010231728.AA03948@braden.isi.edu> < <12632159446.18.BILLW@mathom.cisco.com> > <1662@ruunsa.fys.ruu.nl> <60340@bbn.BBN.COM> <1666@ruunsa.fys.ruu.nl> Sender: news@bbn.com Reply-To: craig@ws6.nnsc.nsf.net.BBN.COM (Craig Partridge) Organization: Bolt Beranek and Newman Inc., Cambridge MA Lines: 28 In article <1666@ruunsa.fys.ruu.nl> muts@fysaj.fys.ruu.nl (Peter Mutsaers /100000) writes: > >>So building a "reliable UDP" is essentially as difficult as doing a TCP. >>And the only reason to do it is that your operating system constrains the >>number of connection blocks you can get, while the UDP interface allows >>you more connection blocks, because you can put the connection blocks in >>your application's memory space, rather than your kernel space (which is >>putting dumb restrictions on you). > >But suppose I want 1000's of processes to be able to communicate. Couldn't >the overhead of just having that many connections become to big if >only few of them communicate at the same time? Let me repeat my assertion, slightly differently. IF you want reliability, THEN you have no choice but to have connection blocks. If you have 1,000's of processes continuously talking, you will have 1,000s (or more) connection blocks. If they are not continuously talking, then you can just as easily deallocate TCP connection blocks as "reliable UDP" connection blocks. >Besides, for my particular application I use the select() system call, which >only operates on the lowest 32 file descriptors. This has suddenly become a UNIX discussion, but read the manual page again. Select uses arbitrary sized bitmasks, and takes a parameter telling it how large the bitmasks passed to it are. [32 is just the maximum size some systems support]. Craig