Network Code

[hailstone]

I've been looking through the network code and I wonder why there is a check for order when it is using TCP. The message even states it shouldn't be out of order.

client_interface.cpp

Code: [Select]

if(nextseq++ != msg.getSeq()) {
throw runtime_error("File fragments arrived out of sequence, which isn't "
"supposed to happen with stream sockets.  Did somebody change "
"the socket implementation to datagrams?");
}

[titi]

But thats what the error mesage says!
Its just a fallback error handling. If someone will change the socket implementation to UDP ( DGRAM  Sockets ) this could happen.
And its absolute realistic that someone will try to change the implementation to UDP one day. TCP has some bad overhead that could be manually optimized when using UDP. I think this check is currently not needed, but it's really ok for future use.

[daniel.santos]

hailstone, this is what we call a "sanity check."  Sanity checks identify problems as soon as possible before they have a chance balloon into more troublesome problems down the road where the cause is harder to identify.  As tit said, somebody could change the underlying layer later on.  This isn't such an outlandish idea if you also consider the headaches caused by trying to go from IPX to IP back in the 90s (yea, I'm dating myself) -- these were massive headaches to overcome, as most games in the early to mid 90s used the IPX protocol only so a lot of hacking was required to get them to work across the Internet (e.g., Kali).

It's also very important for each layer of software to be as loosely coupled (wikipedia article) with other layers for a multitude of reasons.  Thus minimizing the number of assumptions as to what the other layer is or isn't doing is always a good thing, especially when it's something as simple as checking the sequence number which probably translates into about 5 to 7 actual machine instructions at most, once optimized.

If someone will change the socket implementation to UDP ( DGRAM  Sockets ) this could happen.
And its absolute realistic that someone will try to change the implementation to UDP one day. TCP has some bad overhead that could be manually optimized when using UDP. I think this check is currently not needed, but it's really ok for future use.

Yes, very much so!

Code: [Select]

<!-- s]Wireshark[/url] is your friend!). Phuck, I'm a geek!

Sorry for the long post, but you see why keeping layers as loosely coupled as possible is a good thing.  Also, the current GAE network implementation still uses zlib-compressed XML documents and I'm totally for a binary protocol, I just don't think it's worth doing until the other problems are straightened out in the actual game logic layers.

[hailstone]

I suppose I thought that it was unlikely anyone would change it from TCP to UDP while the program was running and if the underlying implementation was changed it would be handled there.

The Spring Engine uses UDP but I've read at GameDev.net that it's good to use TCP and UDP only in extreme cases.

Gamasutra has an interesting article on the Age of Empires networking which uses a peer-to-peer model.

I don't think that any of the problems I'm having in GAE's network play are related to actual networking or data transfer issues, rather that of cooperating with the mechanisms that the Glest engine uses.

The game loop recommended by the Game Production unit at uni has it set out like:
[li]Update Scene-Graph with Network information
[li]Update Scene-Graph via AI
[li]Update Scene-Graph via Physics and Animation
[li]Render Scene-Graph to Screen via Graphics System
[li]Render Scene-Graph to Audio System

Glest has it like this (from program.cpp - Program::loop()):
[li]programState->render();
[li]programState->updateCamera();
[li]GraphicComponent::update();
[li]programState->update();
[li]SoundRenderer::getInstance().update();
[li]NetworkManager::getInstance().update();

I'm not sure how much of a difference it would make.

I would like to have a measure of how much data is being sent over the network (like there is fps). eg 10kbs

[daniel.santos]

I would like to have a measure of how much data is being sent over the network (like there is fps). eg 10kbs

Jolly good idea! =)  (I'm just happy right now from the election, so please tolerate my way-to-smiley posting!!

The Spring Engine uses UDP but I've read at GameDev.net that it's good to use TCP and UDP only in extreme cases.

It's nice to support both because firewalls often get fussy with UDP.  Plus, if you are tyring to play from work or something, they may only open TCP port 80, and you can just play a TCP port 80 game if you choose to  I revamped most of the code involving repairs to use a singular mechanism for healing EPs or HPs and the support is there to replenish locally stored resources as discussed elsewhere, but it's not implemented anywhere else yet, so it's essentially not working yet.  So to add the remainder of the ideas I had for FPM's enlightenment, I would just need static emanations (an effect/emanation that is tied to the map and not a unit) for the monk to cast their <Dieity's Name>'s Favor spell and the astral travel stuff for the acolyte.