[openbeosnetteam] Re: [Update] recent fixes, TODOs
- From: Waldemar Kornewald <Waldemar.Kornewald@xxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Wed, 06 Oct 2004 19:42:17 +0200
Hi Philippe,
Philippe Houdoin wrote:
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 ?
:)
In R5 the fd_set structure is smaller than in BONE (== ours). In our R5
select() emulation we had
memcpy(fd_set,...,sizeof(fd_set))
which caused a buffer overflow because it wrote more data than fitted
into an R5 fd_set.
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!?
;-)
Uhm, when I debugged Mozilla I think connect() returned -1. Do our error
codes have the same value as in BONE?
Anyway, we can easily fix this with a new port. ;)
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.
I am not sure. At least it works with R5 and BONE, so we must be doing
something wrong.
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?
No, it did not work in either mode (my first report was wrong).
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?! ;-)
As long as we are productive... ;) I hope to find more time soon... :)
They probably chose their layout for a good reason...we can still
suggest our changes.
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?
Maybe just that BONE structs are often bigger and never smaller than R5
structs. This should be taken into account in libnet.so.
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? :-)
Yes, Be Inc. was very bad at choosing good values for BONE. We have to
live with it until R5 apps die out (hopefully soon ;).
Bye,
Waldemar
Other related posts:
