|
From: <ebi...@ln...> - 2003-08-03 19:41:15
|
Markus Gutschke <ma...@gu...> writes: > This would be different, if somebody really went to the trouble of > implementing more complicated TCP based protocols (such as the iSCSI > stuff that you mentioned). If there is a lot of data being sent in > both directions, then the TCP implementation probably needs to be more > sophisticated than what I do right now. Even iSCSI would be mostly a read case. Just a whole bunch of read commands probably 64K reads at a time or 512 bytes if we are plain lazy. We don't have write support in any of our disk drivers and I don't see that making any kind of sense, in a bootloader anyway. > As for the more advanced tuning algorithms that modern TCP stacks use > (e.g. slow start, restart after a stopped connection, ECN, ...), I'll > check with my documentation and see if any of those are applicable, > but I don't expect that much of it is useable. Ok. The important thing is that the stack does not have any nasty interaction effects when congestion occurs. Which I know some of the proposed TCP algorithms have. The worse case I can imagine is everyone assuming they have an infinite TCP window and just blasting packets. That only works for one client, and one server, on an unoccupied network. > >>>3) Are alignment considerations that need to be taken care of. > >> > >>??? Can you elaborate what you were thinking of? > > Compilers on non-x86 assume there certain kinds of data are aligned > > to certain boundaries. 4 bytes for a 32bit int for example. Network > > packets have a tendency to misalign structures. > > For running the code on the Itanium for example it is very important > > that we don't have that kind of issue. > > I see. I don't believe any of my code violates any alignment > requirements (other than the HTTP handler calling getdec() in a > slightly broken way; we really should have something like getndec()), > but I am not sure about the OS loaders. The TCP code just hands the > received data off as it gets it. Can all of our loaders deal with > arbitrarily fragmented blocks or do I have to reassemble blocks before > I can hand them off? If I have to do this, what block size do I have > to use? Is any power of two OK, or does it have to be 512 bytes? The hard case is the initial block of data. Which is assumed to have enough information to identify the file formant and to start parsing the file. I believe several of the OS loaders will choke if this is less than 512 bytes. After that we are pretty safe, variable size TFTP blocks need to be handled already. They all are all >= 512 bytes but there is nothing like a power of two requirement. We should be able to handle 513 byte packets without a hitch. Eric |
