Re: [Netconsole-devel] Protocol notes

[<li...@ho...>]

> All packets are encapsulated in UDP datagrams having a port number of
> [21727] on the server side; [21726] on the client side.

> [IS THIS THE BEST WAY TO HANDLE PORT NUMBERS?  A FIXED PORT NUMBER
> SHOULD MAKE REATTACHMENT EASIEST, BUT DOES IT WORK WELL ON THE SERVER
> SIDE?]

Not too evil, but how does the client find out the server's IP address?
DHCP?  The presumed environment (e.g. Beowulf cluster) has a *lot* of clients,
so you don't want to have to configure them manually.

Would it make more sense for the client to broadcast to a statically
assigned multicast address?

Note that there appear to be no way for a server to elicit a response
from a client without sending it data (unless you want to reserve stream
0 for that purpose).  You could formalize this and require that the
client initiate communications, obviating the need to choose a client port.

Is there any way for a server to find out which streams a client supports?

Including the character set redundantly with each packet seems odd.
Think carefully if the number of such "header options" is going to grow.
There are other ways to achieve the same end if that is so
(a way for the client to answer queries from the server, perhaps).


One important thing to note is that the server can use the lock-step nature
to detect missing data.  The client will always transmit the lowest available
unacknowledged sequence number.  If the server sees a packet with a higher
sequence number than it is acknowledging, there has been a data gap.



How does a newly booted server achieve sync with the client?  It can't send
a packet including an ack sequence number, because it might land in the valid
sequence number space.  But the client has presumably backed off to quite
infrequent retrnamsissions, and the server probably doesn't want to
wait that long to establish communications.


Since the assumption here is that we can add almost arbitrary complexity
to the server to allow a lower-resource client, I can suggest at least
one header flag: "client has no timer".  If the client sets this bit, the
server must poll it as some suitable rate.  The client MUST transmit new
data in a stream when it arrives, and SHOULD make multiple transmission
attempts before its buffer space overruns, but it does not do timeout
retransmissions, relying on periodic server polls to tickle it into
retransmission as necessary.


Are there supposed to be previsions for the level-N boot loader to pass
the current sequence number to level N+1?  Should level-N wait for all
its data to be acknowledged before jumping to N+1 (and if so, how long),
or are there provisions for passing the unacknowledged data to level N+1?