[openbeosnetteam] Re: [Update] recent fixes, TODOs

Hi Waldemar,

> here is a little status report (if you did not read CVS):
> I fixed the select() bug and sockaddr_in BONE incompatibility and now 
> many apps finally work. 

Could you expand on the reason why it was broken, so we (I, I mean "I" 
:-) ) can understand what was wrong before and 
what we should take better care of next time to not reproduce these 
issues ?

> ping (Be's):
> Does not work. Incompatible ICMP API? Not a real problem.

Yeah, AFAIK, R5 net_server don't have raw socket and R5 ping rely on 
specific net_server API.
We don't care as we have our "ping" implementation.

> Mozilla & Firefox:
> Does not work because connect() seems to return an error for 
> non-blocking sockets. Don't know why.

http://www.opengroup.org/onlinepubs/009695399/functions/connect.html
According to POSIX, connect() on non-blocking sockets should returns 
EINPROGRESS at first call and EALREADY for others until connection is 
established.
Our code in src/add-ons/kernel/network/core/socket.c::connect() do this 
accordly.

Anyone where live connection code in Mozilla/Firefox source tree!? 
;-)

> ssh:
> A downloaded version from BeBits did not work with R5, but with BONE 
> it 
> had no problems. After a recompile it worked with R5, too.

Sounds like ssh have some sockaddr_* length dependencies in his own 
code, then.
Not really a big issue, anyway.

> ftp (R5, Be Inc.):
> Does not work. Seems to hang in recv() sometimes. Cannot be killed 
> because thread entered kernel.

Did you try with passive mode? Did it change anything?
 
> TODOs:
> Fix the recv() bug that causes ftp to hang.
> Fix connect() for nonblocking sockets.
> 
> Make thread-safe or port FreeBSD's stack. ;)
> I talked to the FreeBSD people and they say that IPv4 is thread-safe, 
> but fine-grained locking is still to be implemented and IPsec and 
> IPv6 
> are not thread-safe, yet. This will be done in the next few months.

I start to look at their code, but I'm not fluent with BSD source code 
layout.
_kern_socket() & co, corresponding to our src/add-ons/kernel/network/
core/socket.c seems to live in src/sys/kern/uipc_syscalls.c. 

We definitivly have a better layouted and named source tree, BTW.
Nothing better and easier than self congratulations, right?! ;-)

> When fixing bugs it might help to know that our structs might be 
> bigger/smaller than the R5 or BONE structs. This was often the cause 
> for 
> buffer overflows in our code.

We should try to be binary compatible for our "public" structs too.
That's hard with network code because public api is really low-level 
kind and use several full or half public structures.
That sucks, but we can't do many thing about it alas.

I tried to list these differences in docs/develop/net/
r5_compatibillity.html, maybe it can be expanded with our newest 
knowledge on these issues?

I'm still hoping we can find a way to transparently detect an R5 app 
from a BONE caller app, so we can simplify the libsocket/libnet/libbind
/libnetapi stuffs. I can dream, can't I?  :-)

- Philippe


--
Fortune Cookie Says:

Graduate life -- it's not just a job, it's an indenture.

Other related posts: