Re: [Etherboot-developers] [RFC] Multicast reception....

[<ebi...@ln...>]

"Anselm Martin Hoffmeister" <an...@ho...> writes:

> > multicast reception mode.  And it seems receiving all multicast
> > packets is widely implemented, and generally easy to setup.
> Another question is how to handle that multicast data.
> 
> > I think I can find a busy network  or two.
> Me, too. Good a dozen clients on an 10MB BNC can be.....making you brew lots
> of coffee. Especially when users start flood pinging (there have to
> winblows-machines on the cable) or transferring gigabytes to the old novell
> server)
> 
> > Given the warning I will start with -DALLMULTI so the driver changes
> > can be enabled/disabled.  For some cards doubtless this will be
> > promiscuous mode.
> 
> You surely are able to enable/disable promiscous mode on the fly, are you?
> So let's just assume - if it is needed at all - that it is only activated
> while retrieving a file (so while one process is near to continuously
> listening on the wire).

An important maintenace feature is to keep the drivers as simple
as possible.  So unless I can confirm there are real world problems
with enabling multicast reception all of the time -DALLMULTI will
be just an option during development.

> > But there is no point in asking for more than I need.
> 
> Please see RFC2090 (tftp multicast). It offers you quite a lot of what you
> need. Can be downloaded from http://www.faqs.org/rfcs/rfc2090.html

It's a good RFC, but it has several problems.  

 - It doesn't fix TFTP's streaming problem.  That is the server has
   challenges to keep the network busy.

 - It requires all clients to be registered.  My design goal is 10,000
   clients.  If something goes wrong 10,000 timeouts can be a real problem.

 - It doesn't handle large files.  (A requirement for using multicast
   transfers for other purposes). 

I already have a tested protocol that is a little simpler on the
server end but it about equivalent on the client end.

> I'm afraid googl'ing didn't hand out any server for that. Perhaps someone
> needs to write one.

atftp almost implements it, but I really don't like it's use of threads.

> Just to describe the additional needs for clients:
> 
> - They have to implement listening on a multicast address arbitrarily given
> by the tftp server
> 
> - They have to keep track of which packages were ok and which were not... 1
> bit to be stored for each 512 bytes of image data to be downloaded. As
> block# is a 16bit-word, we would need 8k of RAM for just the case of an 32MB
> file to be transferred.
> 
> - They have to be able to differentiate between TFTP and TFTP-MCAST files to
> be downloaded...
> Imagine a 1.2kB motd file to be retrieved versus a 1934kB kernel image. In
> first case, initiating an mcast request makes not so much sense,
> does it?

- They have to handle receiving packets in random order.  
 
> So let's assume the multicast ability should be transparent to the rest of
> the prom and should only be programmed inside tftp_getfile (sorry, no idea
> right know how that function is called. Must be something like that) so that
> e.g. the os loader only asks for "/vmlinuz" and does not have any interests
> in the mode how the file comes to the local memory. Do you think it's a good
> idea to have the client always try multicast if that's enabled (remember:
> The server could differentiate after the criterium of [files smaller than
> 10kB -> no multicast], but per specification, multicast servers listen on
> port 1758 instead of 69)? 

There are only 2 cases where multicast is not a win.
1) Very few clients want the file, and lots of people are listening on 
   the multicast ip, (it is being broadcast across a switch).
2) You are in an environment where multicast traffic is much worst than
   unicast trafic.

> We could of course replace the old tftp daemon by
> one that supports multicasting and on the fly decides for us. Or we could
> say all filenames beginning with e.g. the "{" character will be stripped and
> requested by multicast... or both...

Or we can put a URL in the file name field, my preference.  And then
we can compile in the multicast client, the nfs client, and the
classic tftp client, and the the dhcp server decide. 
 
> In any case, it's a lot of work. And it could improve a lot the look&feel,
> what I'm always interested in

It is some work but except for research and protocol scrutinization,
the coding isn't that hard.  The only really hard bit is the work of
stabalization. 

Eric