• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

C++ to Java communication for Game Server

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Our PS2 Game Client software is in C++. I would like to write the new server in Java. The problem I've had with this in the past is that I can neatly create a stuct or class in C++, send it over the wire, cast the data to that same struct/class and easily get all my data.
However, having to serialize it in Java, do the byte array thing and put each byte back in the right place is a major pain and VERY bug prone. It reminds me of hacking in assembler.
There must be a better way. The only thing I can think of is to send all the data as name/value pairs in ASCII and use the StringTokenizer (like message = <userIP=10.65.30.112, userName=MrKrispy> . The problem with that is the data size is much larger than sending it all in binary.
Any ideas or help would be greatly appreciated.
Thanks!
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Have you used ObjectOutputStream and ObjectInputStream? If your Objects are Serializable, this usually works pretty well, and doesn't require a lot of effort from you. When you say serialization is a "major pain" in Java, are you talking about this? Or are you talking about implementing serialization yourself by hand?
 
Russell Patterson
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have not tried that yet and it sounds interesting. However my problem is that I have C++ client on the PS2 and I want to write the server component in Java. So I need to communicate between the two.
If I have a C struct like:
struct myStruct
{
intplayerID;
charrank;
charname[20];
};
and I want to send it over the wire to a Java App. How do I receive it on the Java side without doing stuff like readInt(), readByte(), etc. The big-to little endian thing comes into play too.
Can I use the serialization thing and prepend some info on the C side so that the Java side will now how to interpret it?
Thanks for your help on this.
-Russ
 
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi Russell,
well, at first sight i can see CORBA as solution but of course that involves hassles of its own and its a heavy architecture...and if one dont have a very much use of that why one would put him/her self in a soup?
alternative?
1. what Jim suggested is a good option but the problem here is you have C code at client side. how would you use ObjectOutputStream in that case? may be you can build your own Java Wrapper on client side to encapsulate details in Java object and then use ObjectOutputStream thing but the issue would be probably same "we have to WRAP C structures into Java"..
2. we use JNI probably which provides us with this user defined wrapper thing i mentioned in above point and then corresponding Java object would communicate with server..(may be Jim thought of JNI only while mentioning ObjectOutputStream)
its an interesting issue though to handle it easier way....else we can always write scary code u know (do byte level stuff u don't want to do)
regards
maulin.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry, I missed the fact that the client was still in C++. Forget about the ObjectInputStream/ObjectOutputStream then.
So, are you revising the client too, but leaving it in C++? Or are you leaving it completely alone? If the latter, then you probably can't revise the message format at all - whatever format the client currently uses, that's it. In that case, for the Java side your best bet is probably using DataInputStream / DataOutputStream to provide a slightly higher level of abstraction than the byte-level stuff you dislike so much.
If you're rewriting the client too and are willing to change message formats, you might consider using XML-based messages instead. This allows you to use various preexisting tools to make life a bit easier; it also generally allows others to understand messages much more easily without being tied to a rigid file format. The main down side is that it will increase file size (at least as much as the name/value pair idea, which can be closely approximated in XML if you use attributes rather than elements for most of the data). Parsing may also be slower with XML than a straight byte-reading approach. If this doesn't work for you, then it's probably back to the menthods of the previous paragraph.
 
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
SOAP?
 
Russell Patterson
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We can change the client C++ code. Since I need to send fairly simple messages I will probably use the name/value pair method. So this:
struct myStruct
{
int playerID;
char rank;
char name[20];
};
would be sent as this:
<PLAYERINFO playerID=324, rank=R, name=`MrKrispy`>
It's XMLish but I won't have to add the complexity or size of an XML parser (or SOAP even though it looks like a cool standard, thanks again for the tip). The parser in C++ will be dirt simple and StringTokenizer will make the Java side painless too.
We will probably gzip everything which should alleviate any bandwidth issues.
Thanks again for all the input!
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic