client server framework

[Bizio]

Ok, I am looking to see if someone can point me in the direction of a
simple client server framework for passing messages between two
computers?

Basically I will have two computers on their own, isolated network. I
want to be able to pass messages from the client to a server. The
message contains a state and a command, as well as a data portion. The
data portion can be either a char*, an int, or two ints currently.

I have been looking at sockets, but am fairly new at this. I figure
before I went and invested the time upfront to learn good socket
coding standards, i'd see if there was a good framework out there.

Thanks.

If it helps, i am using Borland C++ Builder 2007. I looked at
http://linuxgazette.net/issue79/tougher.html but was unable to get it
to compile with BCB 2007. I am fairly new to both BCB 2007 and C++ as
I just switched to C++ from Delphi Pascal.

 

[coal]

Ok, I am looking to see if someone can point me in the direction of a
simple client server framework for passing messages between two
computers?

Basically I will have two computers on their own, isolated network. I
want to be able to pass messages from the client to a server. The
message contains a state and a command, as well as a data portion. The
data portion can be either a char*, an int, or two ints currently.

I have been looking at sockets, but am fairly new at this. I figure
before I went and invested the time upfront to learn good socket
coding standards, i'd see if there was a good framework out there.

Thanks.

If it helps, i am using Borland C++ Builder 2007. I looked athttp://linuxgazette.net/issue79/tougher.htmlbut was unable to get it
to compile with BCB 2007. I am fairly new to both BCB 2007 and C++ as
I just switched to C++ from Delphi Pascal.

There are a number of them. One is called Poco -
http://poco.appinf.com/

I'm working on this - www.webebenezer.net. It is more an
alternative to serialization libraries than it is a client
server framework.

Brian Wood
Ebenezer Enterprises

 

[Matthew Crisanti]

Ok, I am looking to see if someone can point me in the direction of a
simple client server framework for passing messages between two
computers?

Other than my own api, for which I haven't yet opened up the source, I am
not aware of any. I'm sure there are plenty, though.

Basically I will have two computers on their own, isolated network. I
want to be able to pass messages from the client to a server. The
message contains a state and a command, as well as a data portion. The
data portion can be either a char*, an int, or two ints currently.

If this is all you want to do, it should be very easy to implement. The
easiest way would be to send the data with a small header that specifies the
type and length of the payload, then deal with the data accordingly on the
receiving end (checking for errors, of course). If you don't need guarantees
about the arrival and the order of arrival of the messages, use UDP.
Otherwise, use TCP. On an isolated network like the one you say you will be
using this on, I think UDP should be fine, unless the network is wireless or
the network is an especially complex one.

 

[James Kanze]

Ok, I am looking to see if someone can point me in the direction of a
simple client server framework for passing messages between two
computers?

Basically I will have two computers on their own, isolated network. I
want to be able to pass messages from the client to a server. The
message contains a state and a command, as well as a data portion. The
data portion can be either a char*, an int, or two ints currently.

I have been looking at sockets, but am fairly new at this. I figure
before I went and invested the time upfront to learn good socket
coding standards, i'd see if there was a good framework out there.

If it helps, i am using Borland C++ Builder 2007. I looked athttp://linuxgazette.net/issue79/tougher.htmlbut was unable to get it
to compile with BCB 2007. I am fairly new to both BCB 2007 and C++ as
I just switched to C++ from Delphi Pascal.

The obvious solution is Corba; although it might be overkill in
your situation, it has the advantage of being standard.

 

[Bizio]

Ok, some clarifications.

The state and command are both of type int. The state is used to
verify that the server is in the correct state, and the the command is
executed from this state.

The data portion varies. Right now I have a structure (includes state
and command) with a union inside it for the data portion. The union
members are 3 seperate char*, an int, a struct containing two ints,
and another int. i broke it down this way to use logical names for the
portions.

I believe that I can cast the structure to const char* and use the
Send() method of Sockets, which is what I am currently doing, but I
would prefer something possibly a little cleaner.

I had found this: http://linuxgazette.net/issue79/tougher.html which
is almost exactly what I am looking for, but am having an issue with
the Expat XML parser installation and Codegear C++ Builder 2007, which
is stopping me from using it at the moment. I am able to compile the
Expat projects, but cannot link the DLL and including the source
directory in the search path still gives me the same error about not
finding the expat.h file.

Thanks for all the suggestions so far. I am going to give them a try.
It seems that my structure might be similar to the message header that
is mentioned above.

Thanks so far.

 

[coal]

The obvious solution is Corba; although it might be overkill in
your situation, it has the advantage of being standard.

From what I can tell Corba is waning. I've never known anyone

who enjoyed working with Corba either. Over the years we've
witnessed many people working on marshalling frameworks
and client server frameworks that have a narrower focus
than Corba. These frameworks are still somewhat immature in
my opinion, but they are steps in the right direction. C++
moves slowly in terms of advancement and yet Corba hasn't
been able to come close to keeping up with C++.
If I were starting a project and expected it to be an ongoing project
I wouldn't select Corba.

Brian Wood
Ebenezer Enterprises
www.webebenezer.net

 

[Alf P. Steinbach]

* (e-mail address removed):

who enjoyed working with Corba either. Over the years we've
witnessed many people working on marshalling frameworks
and client server frameworks that have a narrower focus
than Corba. These frameworks are still somewhat immature in
my opinion, but they are steps in the right direction. C++
moves slowly in terms of advancement and yet Corba hasn't
been able to come close to keeping up with C++.
If I were starting a project and expected it to be an ongoing project
I wouldn't select Corba.

Not to mention that Corba is very complex technology. So it's likely to
be used in ungood ways. Introducing problems, including both technical
and more time than anticipated just to get things working in some way.

Cheers,

- Alf

 

[James Kanze]

From what I can tell Corba is waning. I've never known anyone
who enjoyed working with Corba either.

I like the principles of it. I think that for large projects,
something along the lines of Corba is necessary, and despite its
problems, it's easier to use Corba than to develop your own.

Over the years we've
witnessed many people working on marshalling frameworks
and client server frameworks that have a narrower focus
than Corba. These frameworks are still somewhat immature in
my opinion, but they are steps in the right direction. C++
moves slowly in terms of advancement and yet Corba hasn't
been able to come close to keeping up with C++.
If I were starting a project and expected it to be an ongoing project
I wouldn't select Corba.

If I wanted to play it safe, I'd choose Corba, because it has a
standard, and is supported by several different suppliers
(including some free versions). In sum, for many of the same
reasons I would choose C++: for any given application, I could
probably design a language which was better adapted, but C++ is
standard, and I know that I won't have to implement it myself,
neither now nor anytime in the future. And despite a number of
quirks (the most embarassing parse, etc.), it gets the job done.

In the end, I think my opinion of Corba is about the same as it
is of C++: I can't say that I really find either that good, but
all of the alternatives I've seen seem significantly worse.

 

[R Samuel Klatchko]

Ok, I am looking to see if someone can point me in the direction of a
simple client server framework for passing messages between two
computers?

There are quite a few Remote Procedure Call (RPC) families around. One
of the more recent ones is XML-RPC:
http://www.xmlrpc.com/

> If it helps, i am using Borland C++ Builder 2007.

If you don't care about portability, Microsoft has it's own
implementation of RPC which may be easier to get started:
http://msdn2.microsoft.com/en-us/library/aa378651.aspx

Of if you want to do more research on your own, I would recommend
googling "RPC".

samuel

 

[coal]

I like the principles of it. I think that for large projects,
something along the lines of Corba is necessary,

OK, but what I'm advocating - a C++ oriented solution
with various libraries and frameworks - is less complicated
and could be used in many applications. Once we get that
much sorted out better, we might be able to add support for
another language or two. If you happen to be using only
C++ in your project, Corba seems like a poor choice as it
hinders you from writing concise code. I think that has
been obvious to a lot of people for quite awhile and has
motivated them to work on the alternatives I mentioned.

and despite its
problems, it's easier to use Corba than to develop your own.

Well, that's true, but it doesn't mean it isn't worth
developing an alternative and hopefully improving on things.

I recall a past thread where you said you have developed
some serialization software. Corba has more than serial-
ization support and maybe that is what you are getting at.

If I wanted to play it safe, I'd choose Corba, because it has a
standard, and is supported by several different suppliers
(including some free versions). In sum, for many of the same
reasons I would choose C++: for any given application, I could
probably design a language which was better adapted, but C++ is
standard, and I know that I won't have to implement it myself,
neither now nor anytime in the future. And despite a number of
quirks (the most embarassing parse, etc.), it gets the job done.

I acknowledge there are some similiarities, but I don't find
C++ and Corba to be on the same plane. People put in long
hours attempting to improve C++ and in some cases I think
they succeed. I don't think there is the same sort of
energy with Corba.

In the end, I think my opinion of Corba is about the same as it
is of C++: I can't say that I really find either that good, but
all of the alternatives I've seen seem significantly worse.

Hmm. If you mean in terms of completeness I could agree,
but I'm skeptical of it in terms of its performance and
multi-version support.

I haven't compared my marshalling software to any orb,
but if you are using C++ containers and Corba you have
the performance hit of copying data without any benefit.
Also Corba doesn't support using the hinted inserts that
some containers have.

A standard for serialization of C++ objects could be
developed. One question there would have to do with
version support. The Boost library embeds version
information in its container and UDT support. I'm
not convinced that is a good idea -
http://tinyurl.com/247c8x


Brian Wood
Ebenezer Enterprises

 

[Ian Collins]

OK, but what I'm advocating - a C++ oriented solution
with various libraries and frameworks - is less complicated
and could be used in many applications. Once we get that
much sorted out better, we might be able to add support for
another language or two. If you happen to be using only
C++ in your project, Corba seems like a poor choice as it
hinders you from writing concise code. I think that has
been obvious to a lot of people for quite awhile and has
motivated them to work on the alternatives I mentioned.


Well, that's true, but it doesn't mean it isn't worth
developing an alternative and hopefully improving on things.

As one who has been there and done that with developing an alternative
to Corba, I have to agree with James that unless one can't use Corba,
the arse ache developing an alternative causes just isn't worth it.

If you have a very small set of requirements and a resource constrained
environment, by all means give it a go, you will learn plenty and
probably never do that again!

 

[coal]

As one who has been there and done that with developing an alternative
to Corba, I have to agree with James that unless one can't use Corba,
the arse ache developing an alternative causes just isn't worth it.

If you have a very small set of requirements and a resource constrained
environment, by all means give it a go, you will learn plenty and
probably never do that again!

Are you saying you think the various C++ serialization
libraries and client server frameworks are a waste of time?
That seems an odd pov to me. I think they need more
work, but I also think they would be able to beat
Corba implementations in terms of performance.

Brian Wood
Ebenezer Enterprises

 

[Ian Collins]

Are you saying you think the various C++ serialization
libraries and client server frameworks are a waste of time?
That seems an odd pov to me. I think they need more
work, but I also think they would be able to beat
Corba implementations in terms of performance.

No, I'm saying think very hard before inventing yet another one!

 

[Roland Pibinger]

In the end, I think my opinion of Corba is about the same as it
is of C++: I can't say that I really find either that good, but
all of the alternatives I've seen seem significantly worse.

In 2007 neither Corba not C++ are viable options for distributed
applications any more:
http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=396

 

[coal]

No, I'm saying think very hard before inventing yet another one!

I'm not saying this is right/moral, but it is something of
a survival of the fittest. We're in competition with the
others (Boost/etc) and I would think from your perspective
you would be happy to have more options. It is possible to
use more than one of these frameworks in the same application.
(It's not an optimal solution but as I've said the technologies
are still immature.) We don't have the breadth of some of our
competition, but they aren't able to get very close performance-wise
to us in areas where we do compete.
http://www.seventy7.homelinux.net/comparison.html

Brian Wood
Ebenezer Enterprises
www.webebenezer.net

 

[coal]

In 2007 neither Corba not C++ are viable options for distributed
applications any more:http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=396

I agree with a lot in there, but I didn't find anything in
the article stating that C++ was not viable for distributed
applications today. Why do you think that? What language
would you suggest using? I think C++ is a good choice in
this area and there are many projects, new and old,
around to prove it.

Brian Wood
Ebenezer Enterprises

 

[Ian Collins]

I'm not saying this is right/moral, but it is something of
a survival of the fittest. We're in competition with the
others (Boost/etc) and I would think from your perspective
you would be happy to have more options. It is possible to
use more than one of these frameworks in the same application.
(It's not an optimal solution but as I've said the technologies
are still immature.) We don't have the breadth of some of our
competition, but they aren't able to get very close performance-wise
to us in areas where we do compete.
http://www.seventy7.homelinux.net/comparison.html

Every tool has its own niche, you just have to make sure yours is big
enough to survive in. My current approach is to use the lightest
protocol for the job, built form a kit of parts I've built up over the
years. Most of the time simple XML-RPC is good enough for my needs.

My earlier comments stem form a project where I implemented a light
weight Corba replacement which though (with hindsight, inevitable)
requirements creep, became a full blown orb.

 

[coal]

Every tool has its own niche, you just have to make sure yours is big
enough to survive in. My current approach is to use the lightest
protocol for the job, built form a kit of parts I've built up over the
years.

That makes sense to me.

Most of the time simple XML-RPC is good enough for my needs.

My earlier comments stem form a project where I implemented a light
weight Corba replacement which though (with hindsight, inevitable)
requirements creep, became a full blown orb.

Probably you could use those ideas to start something if
you like. It is an uphill battle, but Corba is not exactly
a difficult thing (technically) to improve on. Then there
is Corba II - Ice. A rabbi once told me, "Nothing grows
in ice." So I think the smaller guys have reason to be
hopeful.


Brian Wood
Ebenezer Enterprises

 

[Ian Collins]

That makes sense to me.


Probably you could use those ideas to start something if
you like. It is an uphill battle, but Corba is not exactly
a difficult thing (technically) to improve on. Then there
is Corba II - Ice. A rabbi once told me, "Nothing grows
in ice." So I think the smaller guys have reason to be
hopeful.

Indeed there is plenty of scope for improvement; Corba has to make
compromises to be language and platform agnostic. Corba is the
adjustable spanner on the box, which still leaves plenty of room for the
language and platform specific box spanners.

Good luck,

 

[Bizio]

While I see a lot of other discussion, I am getting some good feedback
that I will look into.

As for Corba, it is probably way more than I need, since the data I am
passing is only going to be a couple integers and a couple strings.
Portability is not an issue as it will run on a windows 2k/xp network
only, and like I said, the network is isolated.