[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Vrs-development] GDEE Message Buffer Implementation (Was Re: where are
[Vrs-development] GDEE Message Buffer Implementation (Was Re: where are we at?)
Tue, 26 Nov 2002 17:43:46 +0000
On Monday 25 November 2002 18:17, Eric Altendorf wrote:
> > It really is very simple under the hood - perhaps someone would
> > like to write an implementation of it in C# ??
We need a C# class object that implements a 'message buffer'.
It has methods to add data chunks to the buffer and read data chunks from the
buffer. It needs to deal with multiple occurances, and removal of occurances.
The C implementation has been provided as an example - a reference suite if
you like. It is missing the 'remove' function though.
> I could do that if you think it would be useful for development of the
> various modules (network server, service manager, resource manager).
Give it a go. I'd exmaine the C code as pseudo code if I were you, to see
how the message buffer is constructed. Obviously a message buffer created
with the C implementation should be readable and decodable by the C#
implementation, and vice versa. They must be functionally identical.
> > Before C# bits can be written we need a nice C# Goldwater 'class'.
> > I'm willing to divert my attention from doing the C framework to
> > doing the goldwater C# 'class' (which shouldn't take long - but it
> > has to be correct as it may be difficult to change it later as it
> > will define the GW interface!). If I then write down the black-box
> > interface that's in my head for modules A-D in the dgee, then
> > perhaps we could develop the framework together and much faster.
> OK, I think I need some elaboration here. Do you mean a C# class that
> provides a front-end interface to GW, so that our various VRS modules
> and managers can talk via GW?
In reality, now that I've got a C implementation of the message buffer, I'm
probably going to write modules A-D in C as they'll only work out to about
30-40 lines each and provide that code as a 'working' reference for each
modules interface specification.
We've all got something to 'see' and work from.
A. would just be Apache, or just a simple command line client.
B. Checks calls 'C' to verify that the requested service is available and
passes the request onto 'D' if it is, else it returns a failure.
C. Confirms that a service is available for 'B' or returns a requested
webservices byte code for 'D'
D. Requests webservice byte code from 'C', executes it and returns the result
'C' can just look in a directory on disc to see the the compiled webservice
Easy Peasy. No managment functions, no admin, no security, nothing. Just a
simple demo of data path.
re-writing each in C# will be a doddle, but doing it this way gives me time
to think about the C# GW API classes a bit.
By all means give the message buffer implementation a go... some one do it!
make sure all numbers are stored in little endian format etc.
I imagine an implementation that provices something like:
message = new DGEEMessage();
message = new DGEEMessage( byte *stream ); // Instantiate from stored buffer
message.addChunk( ID, Content-Type, data_buffer, length );
long len = 0;
byte *data = 0;
data = message.getChunk( ID, Content-Type, &len );
byte *stream = message.getStream();
Or even split it up a bit by having a chunk object and a buffer object:
chunk = message.getChunk( ID, ContentType );
printf( "Chunk Length : %ld\n", chunk.length() );
printf( "Chunk Content-Type: %s\n", chunk.contentType() );
byte *data = chunk.data();
I perfer the latter to be honest, having a buffer and chunk objects is far
Note that passing the ContentType to getChunk is just for validation
purposes, it is an optional value -> see the C implementation. This might be
a really stupid idea, but allows data for a particular 'ID' to be encoded in
several formats, which will probably be required somewhere!
Chris "must stop designing off the top of my head...."
Technical Architect - netFluid Technology Ltd.
"Internet Technologies, Distributed Systems and Tuxedo Consultancy"
E: address@hidden W: http://www.nfluid.co.uk