Path: utzoo!attcan!uunet!mcsun!hp4nl!ruuinf!ruunsa!fysaj!muts From: muts@fysaj.fys.ruu.nl (Peter Mutsaers /100000) Newsgroups: comp.protocols.tcp-ip Subject: Re: Reliable Datagram ??? Protocols Message-ID: <1666@ruunsa.fys.ruu.nl> Date: 26 Oct 90 08:49:29 GMT References: <9010231728.AA03948@braden.isi.edu> < <12632159446.18.BILLW@mathom.cisco.com>> <1662@ruunsa.fys.ruu.nl> <60340@bbn.BBN.COM> Sender: news@ruunsa.fys.ruu.nl Lines: 30 craig@bbn.com (Craig Partridge) writes: >>There may well be another reason not to use TCP. I for example am busy >>with distributing programs over dozens of workstations. Every program >>must be able to talk to any other one, 30 TCP connections is often the >>maximum possible. >>I could automatically close a connection if a new one must be opened, but >>how do I know if no data is to be read, or underway, to the connection >>I want to close? >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? It would be very helpful if I could use TCP indeed, but have a kind of a 'safe' close, which does indicate if more data could be underway. Besides, for my particular application I use the select() system call, which only operates on the lowest 32 file descriptors. -- Peter Mutsaers email: muts@fysaj.fys.ruu.nl Rijksuniversiteit Utrecht nmutsaer@ruunsa.fys.ruu.nl Princetonplein 5 tel: (+31)-(0)30-533880 3584 CG Utrecht, Netherlands