[openbeosnetteam] Re: socket lib...

BTW, look at

http://cvs.apache.org/viewcvs.cgi/apr/threadproc/beos/apr_proc_stub.c?rev=1.
6&content-type=text/vnd.viewcvs-markup

:)

david

----- Original Message -----
From: "David Reid" <dreid@xxxxxxxxxxxx>
To: <openbeosnetteam@xxxxxxxxxxxxx>
Sent: Wednesday, February 20, 2002 5:23 PM
Subject: [openbeosnetteam] Re: socket lib...


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