Multiplayer Crashes

[firegl]

I downloaded version 3.1.0 of glest, and have been trying to play multiplayer today, but it crashes.

It worked fine for the first few seconds, but as soon as I tried to make workers the game crashes.
It said..
"Error: Unhandled Exception
Error(s) Disconnected"

We tried three times, and it crashed each time after a few second. Everyone was on windows.

[KaSek]

I found a serious problem in Glest 3.0 when I ported it to Mac OS X.

The problem is multi-player using network. Glest directly puts C++ object (NetworkCommand) into data packet when it sends MessageCommandList. And the receiver which receives the packet uses it as C++ object.

To my knowledge, there is no standard to implement the internal structure of C++ object in memory. I don't know about it but I can easily guess that C++ object includes data (or pointers to data) and pointers to method. The pointer means memory address, of course.  Among different platforms, we never expect it works. It's no wander that the receiver crashes using the pointer from different platfrom. Even among the same platforms, it can't work when we use different version of compiler or different optimization level. Not only the value of pointer but also the offset of data could be changed.

I fixed this issue in my Mac version without embedding C++ object in data packet. Please see the source code at:

http://ciderhouse.ivory.ne.jp/wp/english/glest

You can find my additions by searching the word "_NeutralNetPlay_". To reduce the number of modifications, I used ad-hoc way. I hope you integrate the my modifications into the future version of Glest in the sophisticated way.

I also fixed the endian and data alignment problems in the source code. These are also required to exchange data via network. The data alignment depends on CPU, compiler and its options.

[martiño]

KaSeK: you are right that there is no standard way of packing classes in C++, however NetworkCommand is just a bunch of integers and there are no virtual functions on it. So the way all compilers pack it the same, and it doesn't include any pointers.

I really have a lot of experience doing thins like this and non-virtual classes without pointers never where a problem before.

Did you have real problems with this or did you change it as a preemptive measure?

As for the error firegl is getting it is just a disconnect, do you have a good internet connection or are you using a modem or some other slow type?

Code: [Select]

class NetworkCommand{
private:
int16 networkCommandType;
int16 unitId;
int16 commandTypeId;
int16 positionX;
int16 positionY;
int16 unitTypeId;
int16 targetId;

public:
NetworkCommand(){};
NetworkCommand(int networkCommandType, int unitId, int commandTypeId= -1, const Vec2i &pos= Vec2i(0), int unitTypeId= -1, int targetId= -1);

NetworkCommandType getNetworkCommandType() const {return static_cast<NetworkCommandType>(networkCommandType);}
int getUnitId() const {return unitId;}
int getCommandTypeId() const {return commandTypeId;}
Vec2i getPosition() const {return Vec2i(positionX, positionY);}
int getUnitTypeId() const {return unitTypeId;}
int getTargetId() const {return targetId;}

[KaSek]

martiño: Thank you for your reply.

If it works for now, who knows the future?
If a compiler put 1 byte before your data for private usage,
your expectation is broken. We shuoldn't depend on implementation.

In communication area, the transparency of data is mandatory. Object is not data, you know.

[daniel.santos]

Martiño, am I a freak for wanting to see this class packed into a bunch of bitfields?  I started on a VIC20 that had 4k of ram, and it still effects me.  My thoughts are that networkCommandType is probably only 0-16 or 0-32 at the most (5 bits), unitId should probably never exceed 4096 or so (12 bits), commandTypeId is probably less than 32 (5 bits), positionX & Y are probably less than 2048 (unless somebody made a really bit map), etc.

But this only takes 14 bytes, and it still freaks me out! I have a 128kb/s  upstream at home and a 3Mb/s downstream. Do I need counseling?  LMAO!  Yet, I'm sure I could pack all of that into 6 or 7 bytes.

OK, I'm done freaking out, thanks for listening.