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

[Anselm M. H. <an...@ho...>]

> 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).

> 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

I'm afraid googl'ing didn't hand out any server for that. Perhaps someone
needs to write one.
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?

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)? 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...

In any case, it's a lot of work. And it could improve a lot the look&feel,
what I'm always interested in

Anselm