client server framework

Discussion in 'C++' started by Bizio, Sep 24, 2007.

  1. Bizio

    Bizio Guest

    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.
    Bizio, Sep 24, 2007
    #1
    1. Advertising

  2. Bizio

    Guest

    On Sep 24, 12:20 pm, Bizio <> wrote:
    > 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
    , Sep 25, 2007
    #2
    1. Advertising

  3. "Bizio" <> wrote in message
    news:...
    > 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.
    Matthew Crisanti, Sep 25, 2007
    #3
  4. Bizio

    James Kanze Guest

    On Sep 24, 8:20 pm, Bizio <> wrote:
    > 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.

    --
    James Kanze (GABI Software) email:
    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
    James Kanze, Sep 25, 2007
    #4
  5. Bizio

    Bizio Guest

    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.
    Bizio, Sep 25, 2007
    #5
  6. Bizio

    Guest

    On Sep 25, 3:16 am, James Kanze <> wrote:
    >
    > 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
    , Sep 26, 2007
    #6
  7. * :
    > On Sep 25, 3:16 am, James Kanze <> wrote:
    >> 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.


    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

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Sep 26, 2007
    #7
  8. Bizio

    James Kanze Guest

    On Sep 26, 5:57 am, wrote:
    > On Sep 25, 3:16 am, James Kanze <> wrote:


    > > 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.


    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.

    --
    James Kanze (GABI Software) email:
    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
    James Kanze, Sep 26, 2007
    #8
  9. Bizio wrote:
    > 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
    R Samuel Klatchko, Sep 27, 2007
    #9
  10. Bizio

    Guest

    On Sep 26, 6:00 am, James Kanze <> wrote:
    > > 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,


    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.

    > > 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.
    >


    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
    , Sep 27, 2007
    #10
  11. Bizio

    Ian Collins Guest

    wrote:
    > On Sep 26, 6:00 am, James Kanze <> wrote:
    >>> 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,

    >
    > 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.
    >

    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!

    --
    Ian Collins.
    Ian Collins, Sep 27, 2007
    #11
  12. Bizio

    Guest

    On Sep 26, 8:53 pm, Ian Collins <> wrote:
    > wrote:
    > > 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!
    >


    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
    , Sep 27, 2007
    #12
  13. Bizio

    Ian Collins Guest

    wrote:
    > On Sep 26, 8:53 pm, Ian Collins <> wrote:
    >> wrote:
    >>> 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!
    >>

    >
    > 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!

    --
    Ian Collins.
    Ian Collins, Sep 27, 2007
    #13
  14. On Wed, 26 Sep 2007 05:00:40 -0700, James Kanze wrote:
    >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


    --
    Roland Pibinger
    "The best software is simple, elegant, and full of drama" - Grady Booch
    Roland Pibinger, Sep 27, 2007
    #14
  15. Bizio

    Guest

    On Sep 27, 2:10 pm, Ian Collins <> wrote:
    > wrote:
    > > On Sep 26, 8:53 pm, Ian Collins <> wrote:
    > >> wrote:
    > >>> 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!

    >
    > > 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!
    >


    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
    , Sep 28, 2007
    #15
  16. Bizio

    Guest

    On Sep 27, 3:15 pm, (Roland Pibinger) wrote:
    > On Wed, 26 Sep 2007 05:00:40 -0700, James Kanze wrote:
    > >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



    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
    , Sep 28, 2007
    #16
  17. Bizio

    Ian Collins Guest

    wrote:
    > On Sep 27, 2:10 pm, Ian Collins <> wrote:
    >> wrote:
    >>> On Sep 26, 8:53 pm, Ian Collins <> wrote:
    >>>> wrote:
    >>>>> 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!
    >>> 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!
    >>

    >
    > 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.

    --
    Ian Collins.
    Ian Collins, Sep 28, 2007
    #17
  18. Bizio

    Guest

    On Sep 28, 3:29 pm, Ian Collins <> wrote:
    > wrote:
    > > On Sep 27, 2:10 pm, Ian Collins <> wrote:
    > >> wrote:
    > >>> On Sep 26, 8:53 pm, Ian Collins <> wrote:
    > >>>> wrote:
    > >>>>> 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!
    > >>> 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!

    >
    > > 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.


    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
    , Sep 29, 2007
    #18
  19. Bizio

    Ian Collins Guest

    wrote:
    > On Sep 28, 3:29 pm, Ian Collins <> wrote:


    >> 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.
    >

    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,

    --
    Ian Collins.
    Ian Collins, Sep 29, 2007
    #19
  20. Bizio

    Bizio Guest

    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.
    Bizio, Oct 2, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark
    Replies:
    4
    Views:
    1,707
    Juan T. Llibre
    Nov 17, 2005
  2. g
    Replies:
    2
    Views:
    686
  3. -
    Replies:
    2
    Views:
    387
    Alan Krueger
    Jul 29, 2005
  4. pizza
    Replies:
    1
    Views:
    519
    Eliyahu Goldin
    Mar 8, 2007
  5. Rachel
    Replies:
    1
    Views:
    912
    Rachel
    Dec 10, 2007
Loading...

Share This Page