My client application is written in C/C++ and runs on Windows.

Then, on the server side I have Linux, with a Java or Oracle listening
for queries.

My problem is the large number of arguments going back and forth. What
I have been doing is to pass all the arguments in a colon-separated
string, or even in several lines (separated by <CR>). It has becoming
increasingly troublesome to keep the client and server programs in
sync.

I keep on hearing about serialization, but have never used it. This
seems to be the problem that serialization is supposed to solve.

I would like to serialize my data in C/C++ before sending it to the
server and unpack the multiple results.

Is there any package out there, written in C/C++ that will prepare the
serialized "packets" and unpack them?

TIA,

-Ramon

Ramon F Herrera wrote:
> My client application is written in C/C++ and runs on Windows
>
> I would like to serialize my data in C/C++ before sending it to the
> server and unpack the multiple results.
>
There's no such language as C/C++. There's C and there's C++, how one
serialises data differs significantly between the two. Which one are
you using?

--
Ian Collins.

On Feb 25, 2:07 am, Ian Collins <ian-n...@hotmail.com> wrote:
> Ramon F Herrera wrote:
> > My client application is written in C/C++ and runs on Windows
>
> > I would like to serialize my data in C/C++ before sending it to the
> > server and unpack the multiple results.
>
> There's no such language as C/C++. There's C and there's C++, how one
> serialises data differs significantly between the two. Which one are
> you using?
>
> --
> Ian Collins.

Thanks, Ian.

I am willing to program the relevant code in either C or in C++
depending on which ones is more convenient for interfacing with Java.

-Ramon

Ramon F Herrera wrote:
> On Feb 25, 2:07 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> Ramon F Herrera wrote:
>>> My client application is written in C/C++ and runs on Windows
>>> I would like to serialize my data in C/C++ before sending it to the
>>> server and unpack the multiple results.
>> There's no such language as C/C++. There's C and there's C++, how one
>> serialises data differs significantly between the two. Which one are
>> you using?
>>
>
> Thanks, Ian.
>
> I am willing to program the relevant code in either C or in C++
> depending on which ones is more convenient for interfacing with Java.
>
Then you are probably better of in C++. There isn't any native
serialisation support in C++, so you will either have to search for a
package that in compatible with Java, or roll your own which isn't too
big a deal.

--
Ian Collins.

Ian Collins wrote:
> Ramon F Herrera wrote:
>> On Feb 25, 2:07 am, Ian Collins <ian-n...@hotmail.com> wrote:
>>> Ramon F Herrera wrote:
>>>> My client application is written in C/C++ and runs on Windows
>>>> I would like to serialize my data in C/C++ before sending it to the
>>>> server and unpack the multiple results.
....
>> I am willing to program the relevant code in either C or in C++
>> depending on which ones is more convenient for interfacing with Java.
>>
> Then you are probably better of in C++. There isn't any native
> serialisation support in C++, so you will either have to search for a
> package that in compatible with Java, or roll your own which isn't too
> big a deal.
>

Java interfaces nicely with C++ with its JNI interface, and some
compilers will automatically generate the Java headers for you.

Serialization usually refers to the preparation of an object so
that it may be placed in persistent storage and restored from there.

The problem of packing and unpacking results between a client
and server is more closely related to marshalling.

Rather than concentrating on a low-level protocol in which you
must specify the marshalling of arguments, can you use a more
abstract interface in which your Java objects and C++ objects
interact via CORBA or SOAP? For CORBA objects I've used both
the TAO IDL and the AT&T Omniorb. For SOAP I've had great
success with gSOAP. I think its easier to use CORBA between
Java and C++.

Glen

On Feb 25, 6:23 am, Ramon F Herrera <ra...@conexus.net> wrote:
> My client application is written in C/C++ and runs on Windows.

> Then, on the server side I have Linux, with a Java or Oracle listening
> for queries.

> My problem is the large number of arguments going back and
> forth. What I have been doing is to pass all the arguments in
> a colon-separated string, or even in several lines (separated
> by <CR>). It has becoming increasingly troublesome to keep the
> client and server programs in sync.

By keeping the client and server programs in sync, what do you
mean exactly? Making sure that both are using the same version
of the protocol? Or is it a problem of one of the two loosing
its place in the data stream.

> I keep on hearing about serialization, but have never used it.
> This seems to be the problem that serialization is supposed to
> solve.

It seems to me you are using it. You're sending data on a
serial link, and recoving it on the other side.

> I would like to serialize my data in C/C++ before sending it
> to the server and unpack the multiple results.

> Is there any package out there, written in C/C++ that will
> prepare the serialized "packets" and unpack them?

There are a lot of them, but I don't see where they'll solve the
problem you have.

The surest solution is to use a self-identifying representation
for the data. If the data have a complicated structure, or
you're already using XML elsewhere in the project, and have the
parser, you might consider XML. In most cases, however, it is
overkill, and simply sending attribute-value pairs will be
largely sufficient. Then code so that missing attributes have a
default value, and extra attributes are ignored (except for
generating a message in the log), and your code should be able
to handle most version changes without problems, and will always
know exactly where it is in the data.

This does result in a lot more data on the line. If this is a
problem, the version control problem can also be handled by
protocol negociation on connection.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Feb 25, 4:46 am, James Kanze <james.ka...@gmail.com> wrote:

> By keeping the client and server programs in sync, what do you
> mean exactly? Making sure that both are using the same version
> of the protocol?

That's what I mean. When I add a new field or move them around, I have
to place my finger on the screen and count the arguments. Then I get
busy working on one program and neglect to change the protocol in the
other affected programs.


>
> The surest solution is to use a self-identifying representation
> for the data. If the data have a complicated structure, or
> you're already using XML elsewhere in the project, and have the
> parser, you might consider XML. In most cases, however, it is
> overkill, and simply sending attribute-value pairs will be
> largely sufficient.

I arrived to the same conclusion (the attribute-value pair approach),
thanks for providing confirmation.

The most complicated data I have is a table. The XML parsing will have
to wait for a harder problem. It is an overkill for this.

Thanks!

-Ramon

On Mon, 25 Feb 2008 05:23:54 -0800 (PST), Ramon F Herrera wrote:
> That's what I mean. hen I add a new field or move them around, I
> have to place my finger on the screen and count the arguments. Then
> I get busy working on one program and neglect to change the protocol
> in the other affected programs.

Why don't the affected programs share the common library code that
defines the protocol?

/gordon

--