Re: [uml-devel] uml_router

[Jeff D. <jd...@ka...>]

hn...@ma... said:
> a) It seems to have inherited the O_ASYNC bug from the previous
> toolset/drivers.

Yup.  Fixed.

> If you are not interested in receiving SIGIO the do not enable O_ASYNC
> as it will kill your program with SIGIO sooner or later...

SIGIO appears to be ignored by default, so this is somewhat harmless.

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

> c) The above is also true for the data receiver, if select should
> happen to falsely indicate data is available (can happen on UDP
> connections in OOM conditions) 

I'll have a look at this.

> d) It seems the binary and object file is checked into CVS... 

Oops.  Fixed.

> e) Blocking conditions are not detected on writes to connected UML's,
> causing the connections to be dropped on larger amount of traffic. 

I'll have a look at this too.

>  f) The "router" seems to try to be too smart for it's own good,
> trying to act as a ethernet switch but not knowing how to properly
> switch a ethernet (there are a wide range of broadcast ethernet
> addresses, not only FFFFFFFFFF). Also, it only supports a single
> ethernet which is a big drawback compared to um_eth_serv.

OK, this is a good point.

I'll make it a dumb broadcasting hub, and give it a switching mode later.

> Proper handling of case 'e' is not trivial for STREAM connections
> (which seems to be the case of UML machines connecting to the
> "router"), as a partial message may be queued.

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.

> (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?

Thanks for going over it like that.

				Jeff