|
| Re: [CDO-Net4j] [message #1000664 is a reply to message #1000548] |
Tue, 15 January 2013 07:56  |
|
Am 15.01.2013 02:03, schrieb Shahim Essaid:
> Hi all,
>
> Does anyone know of any Net4j wire protocol documentation other than the source code? I am considering using Net4j to
> communicate with a Prolog system but I will need to be able to parse the TCP stream on the Prolog side. I need to
> know about the various headers and how to parse them, decode them , etc.
>
> If the source code is the only option, can you please give few pointers to the classes involve in the TCP input and
> output and an overview of how they work together? Any description that explains how a Net4j protocol is translated to
> bytes on the wire would be very helpful.
I don't know of a good wire protocol documentation (well, there are JavaDocs on all of the involved types) and I don't
have the time right now to write one up. So just a few pointers:
The physical connection is represented by an IConnector, in your case a TCPConnector that wraps a
java.nio.channels.SocketChannel. The data units exchanged are represented by IBuffers. The buffers send to or received
from an IConnector belong to one or more IChannels (they're multiplexed through the physical connection). Each IBuffer
starts with a 4 byte header, 2 bytes (short int) for the associated channelID and 2 bytes (short int) for the payload
length stored in that buffer.
If that buffer-oriented, non-blocking communication paradigm is to inconvenient for your application you can decide to
use an ISignalProtocol on top of that low-level transport layer. A signal is an implementation of the client/server
paradigm (request ->indication + optional response -> confirmation). Signals "live" in the payload area of the IBuffers.
The first buffer of a signal reserves another 6 bytes header, 4 bytes (int) for a correlationID that correlates the
buffers of the signal sequence and 2 bytes (short int) for the signalID that Net4j uses to associate the appropriate
processing logic (ISignal implementation) with the signal data. All subsequent buffers of a signal carry just the 4
bytes correlationID. The remaining paylod of the signal buffers forms a stream that is re-assembled by Net4j and passed
into the following methods of *your* signal classes:
org.eclipse.net4j.signal.IndicationWithResponse.indicating(ExtendedDataInputStream)
org.eclipse.net4j.signal.RequestWithConfirmation.confirming(ExtendedDataInputStream)
I hope that helps.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.03704 seconds
] 
Search
Help
Register
Login
Home
