Sign in to follow this  

Network Packages?

This topic is 4206 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello everyone, I'm writing a little multiuser game and i ran into a problem. I am useing Structures to communicate and i am useing the solution thats given in the FAQ like this:
 struct PlayerPosPacket {
    unsigned short code;
    unsigned short player;
    float pos_x, pos_y, pos_z;
    float vel_x, vel_y, vel_z;
    float heading;
  };

  PlayerPosPacket packet;
  packet.code = PLAYER_POS;
  packet.player = thePlayerId;
  ...
  int r = sendto( sock, (char const *)&packet, sizeof(packet), 0, (sockaddr *)&dst_addr, sizeof(dst_addr) );
  if( r < 0 ) { error(sock); }

  union {
    PlayerPosPacket playerPos;
    SomeOtherKindOfPacket someOther;
  } recvPacket;

  int r = recvfrom( sock, (char *)&recvPacket, sizeof( recvPacket ), 0, (sockaddr *)&src_addr, sizeof(src_addr) );
  if( r < 0 ) { error(sock); }
  /* assume all packet types start with unsigned short code; */
  switch( recvPacket.playerPos.code ) {
    case PLAYER_POS:
      if( r != sizeof(recvPacket.playerPos) ) { formatError(); }
      do_playerPos( recvPacket.playerPos, src_addr );
      break;
    case SOME_OTHER:
      if( r != sizeof(recvPacket.someOther) ) { formatError(); }
      do_someOther( recvPacket.someOther, src_addr );
      break;
    ...
  }

The problem i ran into is the following: Sometimes the recv-method isnt fast enough and so are more than one packages in the buffer. since i take things out of the buffer and then check for its size i get an error because the package is now twice the size. Since i am useing diffrent packeges i cant just divide tham since i never know which ones are in the buffer. Can anyone point me to a solution for this problem? Or anywhere i could read more on this? Thx a lot in advance!

Share this post


Link to post
Share on other sites
The general way of doing this is to have a base class which contains a message type and a message size. Then, when you read, you just read the header, then read that number of bytes. E.g.

struct Message
{
unsigned int nID;
unsigned int nSize;
};

struct Something : public Message
{
char szBuff[32];
};
#define MESSAGE_SOMETHING 1

struct Blah : public Message
{
float x, y;
};
#define MESSAGE_BLAH 2


When you read the data, you read sizeof(Message) bytes. From there, you can tell the size of the message, and the message type.

Share this post


Link to post
Share on other sites
hmm that sounds good:)

is there a way you could show me an example or tell me where i could find an example of how a message is received then?

thx a lot for your response

Share this post


Link to post
Share on other sites
You could also try doing what the Etwork library does, which is read everything into a buffer, and then parse messages out of that buffer as they become available.

Get the source, and read through it; it has some classes you can re-use.

Share this post


Link to post
Share on other sites
hmm i just tried it but somehow i dont get how to implement it:)

how am i supposed to find out if there are two or more structs in the buffer when i read it or just one

can you show me what the receiving part of the code would look like?

Share this post


Link to post
Share on other sites
The Etwork library already implements that. It puts all the data in the buffer, and then it checks whether there's enough data in the buffer to cover the packet that the initial part of the buffer claims is there. Each packet starts out with a two-byte length, plus a two-byte packet ID, IIRC. Thus, when buffer is < 4 bytes, no packet can be there. Else, when buffer >= length (taken from the two first bytes) then you have a packet. Remove the packet from the buffer, leaving the rest of the data there (as that'll be the beginnings of a new packet).

Really, just get the Etwork source and read it. Start at "recvfrom()" and go from there.

Share this post


Link to post
Share on other sites

This topic is 4206 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this