[openbeosnetteam] Re: [Update] recent fixes, TODOs
- From: "Philippe Houdoin" <philippe.houdoin@xxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Wed, 06 Oct 2004 17:46:54 +0200 CEST
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:
