[openbeosnetteam] Re: socket lib...

  • From: "David Reid" <dreid@xxxxxxxxxxxx>
  • To: <openbeosnetteam@xxxxxxxxxxxxx>
  • Date: Wed, 20 Feb 2002 17:23:58 -0000

> > I'm sure there's more that I haven't listed, but that's the basic.
> > What I
> > can't figure out (and again I've been up all night so this may be
> > obvious)
> > is how we do this. I mean we have a server running as a process and
> > the
> > stack lives within that process. So, we need to somehow call into the
> > stack
> > to pass in/out data, but that's the bit I don't get. I could see the
>
> More or less the only way to communicate to other teams (regardless on
> which side of the system) is via ports/areas/semaphores and a command
> queue.

Right.

> Basically, we could have a shared area between the server and each
> client using libsocket.so. In this area, we put our commands on the
> client side, and "parse" them on the server side, and put back results
> in there.
> Now we can use port communication to tell the server: hey, there is a
> new command in the queue at offset x. The client and the server have to
> communicate the area_id to share first, of course.

So basically we do this...

The socket library :
- on a call to open it allocates an area of a given size (say 4096 bytes)
and passes the area_id into the "socket_server" which then just clones it...
- the server returns the fd it's allocating

- when the client calls bind/connect or any of the other things it passes in
a request structure that the server just uses (based in the shared area)

- when calling read/write the buffer is simply passed in, again as a pointer
to the shared area...

The communication is done via msgs... We should be able to use a single
thread per client-server connection I think, though we'd have to look at
that.

Also, this won't be pretty but it's possible. Of course the other way of
doing it would be to use a pipe for read/write and just have use the msgs
for control functions. In fact that might be better and much faster with
less bother about having to have huge buffers hanging around.

In that scheme we'd do as above but the socket call would create a pipe and
pass the ends back to the client to deal with. Hmm, lots of questions!

For all of this we probably need the server end of this so I'll try to start
on that next.

david



Other related posts: