Path: utzoo!utgpu!watserv1!watmath!att!att!emory!wuarchive!zaphod.mps.ohio-state.edu!usc!bbn.com!craig From: craig@bbn.com (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols) Message-ID: <60282@bbn.BBN.COM> Date: 23 Oct 90 13:59:48 GMT References: <9010221418.AA03839@ftp.com> Sender: news@bbn.com Reply-To: craig@ws6.nnsc.nsf.net.BBN.COM (Craig Partridge) Organization: Bolt Beranek and Newman Inc., Cambridge MA Lines: 24 In article gnb@bby.oz.au (Gregory N. Bond) writes: >Well, on a similar note.... > >Consider a net with a server and many (say, 100) workstations, and a >data feed that goes to each workstation. At the moment, I have to >open 100 TCP streams, and so each packet of data generates 200 TCP >packets, all more-or-less identical. What would be nice would be to >broadcast the packet to the local net, and have the clients request >missed packets, thus implementing a sort of reliable broadcast. There's been some muttering over beers that this might be feasible in TCP. If you think about the idea, it isn't so crazy. To make sure the workstations are in sync, you'll need some sort of windowing mechanism. To be sure everyone has data, you'll need an acknowledgment scheme. That's pretty close to the basic service TCP offers. So if you could open a TCP connection to an IP multicast address, and figure out how to handle the remote ends cleanly at the sender, you'd be pretty far along. (And 1 sending workstation gets, at worst, 100 acks from 100 receivers -- less if receivers ack every 2nd segment). I believe Van Jacobson and Jon Crowcroft looked at this problem in more detail and may well have something more to add. Craig