Dear Charles,
in message DF2B720CF774D21189EE00805FA7FA220B909B75@nmrusdunsx3.nielsenmedia.com you wrote:
It is a unavoidable fact of standard client/server pairs that the client has a-priori knowledge about the server, the server has no a-priori knowledge about the client. If the target is a multicast server, there is NO NETWORK
This is wrong. The only a-priori knowledge needed by the client to ruin any of the standard network boot protocols (like BOOTP or DHCP) is it's own MAC address, which should have been programmed by the manufacturer and which will never need to be changed.
SETUP AT ALL. In the case of target-as-client, the client must know at least the server's IP address (or DNS name). That knowledge increases the amount of setup. Further, during the course of maintenance and expansion,
I disagree. For standard network boot protocols no such knowl;edge is required.
whether this is acceptable to the customer. My experience is that making the amount of information used by the client (that can be unilaterally changed by the MIS department) nil is the best approach.
The use BOOTP or DHCP.
The key to this is that my download server uses standard UDP over multicast IP. This has a number of advantages, including the fact that the download
You mention "standard UDP" - but are you using a standard download protocol?
Another advantage is that this technique can be used very early in the manufacturing process to load the software (via UDP/IP) that programs the MAC address (as well as model and serial numbers) into EEPROM. When this software is loaded, the target has no IP address or MAC address. I can even load many units in parallel on a test rack.
OK, this obviously means that you are NOT using any standard protocols. I understand that such a solution might make sense for you (although I think that error handling is not easy to implement), but IMHO there are already more than enough proprietary protocols and devices that cannot talk to each other just because the manufacturer tried to be especially clever.
As I wrote before:
U-Boot shall use standard protocols and interfaces whenever possible.
My server-loader meets all of these criteria, except the "powerful to use"
Which is the standard protocol you are using, then? [Note: UDP alone is _not_ a download protocol.]
My loader uses standard protocols as well. It uses UDP over multicast IP.
C'me on. UDP is _NOT_ a file transfer protocol.
You mentioned in a subsequent email to Brian that he would have to write a custom client. You are quite correct. My version of this client is written as a command-line tool that does the following: 0) create a standard multicast UDP socket and bind it appropriately, 1) open a file for binary read, 2) read 1k blocks from the file, 3) prefix a small payload header, and 4) send the block to the socket. Since we already had a socket library, this task took an afternoon and the result was just 5-6 pages of C code.
This is OK, and there is no reason for you not to use such a proprietary approach.
This client hasn't been maintained after it's original creation and testing (although it has been extended with new features; e.g., alternate binary file formats, etc.).
This requirement can be also met with U-Boot using widely available standard protocols (like DHCP or BOOTP).
I'm sorry, but IMHO there is no advantage running a server in the boot loader.
I'm sorry, but IMHO YHO is wrong. :-)
Well, YMMV ;-)
Ultimately, I believe the difference in the two approaches is in where the control is. I prefer to view the host as "in control" and the target as subservient. It has simply been my experience, over many projects, that this way works out better.
The only argument I want to reopeart here is that in my experience the use of open standards is a very strong benefit for everybody, and if there is a solution for a problem based on standard protocols and interfaces I do not want to use or invent some proprietary solution instead.
This whole discussion may not be appropriate on this list. Since I did this
I don't think so. It may be beneficial to many people, one way or another. To be honest, the idea of running a server on the target never even crossed my mind before. It is always a good thing to discuss alternative solutions - and if it's only to come to the conclusion that everything was done correctly :-)
work as a paid employee, I must honor my employeer's policies that prevent sharing source code. I can, however, freely discuss the details and answer questions If Brian or anyone else cares to find out more about this technique, they are welcome to contact me directly.
Thanks!
Best regards,
Wolfgang Denk