Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!mit-eddie!bu.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!CS.UCL.AC.UK!J.Crowcroft
From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Reliable Broadcasts? (was Re: Reliable Datagram ??? Protocols)
Message-ID: <9010261332.AA00997@ucbvax.Berkeley.EDU>
Date: 26 Oct 90 10:17:03 GMT
References: <60282@bbn.BBN.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 37



 >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,

 we kind of figured out the small change necessary to TCP

essentially, you send to multicast address, but receive acks from each
member of the multicast groups individual clas a-c addresses

you have a tcpcb per member, and run each connection state machine as
normal, but link the tcpcb's so you know its a group communcation

to start the whole shebang, you send a syn to group, you get syn acks
back and gradually build up the set of tcpcb's (instead of just
alocating one at start)...when you have the full group connection, you
then allow the sender to do writes on the socket...

each write may block if we are still flow controlled or not acked on
any one connection...

for a many to one (i.e. lotsa folks sending to us) you can overload
the readv interface, and return a vector of single reads...

it shouldnt take a bright person with BSD source more than a day to
change, and a week to debug...

the same thing could be done with broadcast, without the multicast IP,
but is certainly a VERY BAD IDEA:-)

 jon