Re: [Firebird-devel] xnet update

[David J. <dav...@di...>]

Very cool.  I forgot, but I hope you are doing this in a firebird-2
compatible manner.

I have a lot of trouble understanding the wire protocol from the C code. 
You may possibly find it useful to look at the java driver which implements
the xdr stuff in java.  In particular the jgds classes have all the low
level stuff in them.

Is there much chance that the server side of what you are doing will be
usable with a java/jni client?  I'm not entirely clear to what extent the
xnet is tied to windows.

Thanks
david jencks

On 2002.04.16 19:49:13 -0400 William Baker wrote:
> 
> I'm working on xnet.  The more references I find to the file and
> what people have said about it, the more I respect the problem
> and the more I realize that there are lots of people who will be
> looking over my shoulder when it is done.
> 
> I hacked a version of the current xnet code and showed that with
> a little care it can be made to work.  This code, though working
> in the emulator, is unstable on some Win32 platforms and has resource
> and security issues.  Rather than release this code, I would rather
> focus on a clean reimplementation that addresses most of the
> resource and security the issues.
> 
> I may be making too many assumptions about the protocol
> and how it is used.  In particular, I would appreciate corrections,
> clarifications, and confirmations:
> 
> - No documentation of the over-the-wire protocol exists. Any
>    notes on the protocol are appreciated.
> - Are there any tools/techniques/compier options to log and
>    analyze the over-the-wire protocol?
> - XNET will closely mimic the over-the-wire protocol used by
>   other transports, right down the XDR, since it is the encoding
>   mechanism used by all the other transports.  I don't want my
>   own encoding mechanism.
> - Messages are asynchronous: no application level ACK.
> - As asynchronous messages, the client may issue requests
>   back-to-back.
> - Multiple client threads can access the same connection
>    ** it is important to know if this can happen **
> - The aux_* stuff is used for OOB type messages, i.e., request to
>    cancel a transaction in progress.
> -  In other transports implementations, is there a maximum packet
>     size, or is that handled by the underlying transport mechanism?
>     I would like to take advantage of any existing fragmentation methods.
>     I must manage fragments in XNET, since our memory window is
>     (currently, perhaps optimally) a fixed size.
> 
> I am concentrating on a Windows implementation, which may
> eventually be followed by a Unix implementation tested on Linux.
> 
> My goal is to produce a client which blocks for the server, and
> a server which creates a single blocking thread for each client
> connection.  A little asymmetric.  A single non-blocking thread
> will serve all XNET client connection and notification requests.
> The client will notify the server using SendMessage()...win32.
> The notification messages will trigger an event in another (server)
> thread to actually process the message.
> 
> The server will spawn a single thread for each client.  That thread
> will monitor the client to see if it dies and wait for notifications. 
> This
> is basically a WaitForMultipleObjects( pid_dies | message-event ),
> then clean up the resources upon death or close.  There are three
> resources for each connection consisting of a shared memory area, a
> single semaphore (I would like an un-named client side Mutex, but
> probably need a cross-process named semaphore, depending on the
> asynchronous nature of the protocol), and a server-side event
> (CreateEvent() style).
> 
> Sounds simple so far, right?
> 
> wlb
> 
> 
> 
> 
> _______________________________________________
> Firebird-devel mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
> 
>