Jeff Dike wrote:
> > b) listen_fd is not made non-blocking, causing the uml_router to hang
> > if a connection attempt fails (aborted before accept completetion).
> In this case, will the accept descriptor just become quiet until the next
> connection attempt?
The basic problem is that select/poll may falsely indicate that a descriptor is
ready for reading/writing when it in reality is not (or might be when the
select/poll call is executed, but status changes before the actuall I/O call). If
you are doing non-blocking I/O then all your filedescriptors should be flagged
with O_NONBLOCK, and all your accept/read/write/recv/send calls must look for
EAGAIN/EWOULDBLOCK. If you do not then odd things will happen under load.
To answer your question, yes the descriptor will just become quiet, but you may
have to call accept() at least once to clear the status.
> The stream connection is used only for control traffic, not data traffic. And
> it's currently used only to establish the UML on the network.
Hmm.. right. I confused the filedescriptors a bit there. Sorry.
As it is indeed the DGRAM connection you use to send packets then you do not have
a problem with transmissions as it is now, only a minor problem with receives
where the router may (temporarily) block until another data packet is received.
However, solving blocking receives by making the DGRAM socket non-blocking will
force you to deal with non-blocking transmissions...
Normally what an application using non-blocking I/O does on writes is to have a
user-space queue of packets to transmit and then select for write on the sending
socket. When the socket is ready, write to it until your write queue is drained
or the socket returns EAGAIN/EWOULDBLOCK.
> > (think it should read nibble above, not byte..)
> So, if the second byte is 0xab, with 'a' being anything and 'b' being odd,
> that's a broadcast address?
I think so, but I haven't yet found any 100% foolprof reference on the subject.
What I do know is that this is what makes sense from comparing normal and
multicast MAC addresses, the little documentation I have found on the subject,
and is also how the Linux kernel classifies ethernet frames..
For the router/switch you do not need to care about the disctinction between
BROADCAST and MULTICAST. Both are simply broadcasts on a ethernet.
However, non-switched communication are also very handy in some setups where
UML can be expeted to be used by a large population of users, and that is when
testing new networking features. In such setups you often need to be able to run
tcpdump on another node not directly involved in the communication you are