Good, I need a send class with SDL_net using SDLNet_TCP_Send, as I can make a send class?
My Class
Class User {
char username[50];
char message[255];
};
User username;
SDLNet_TCP_Send(sd, (class *) username, len)
Send Class with SDL_net
Something like that will work. len would be sizeof(User) here. The key is to ensure the data structure is POD, in particular it must not contain pointers. You also want to take care of data size and endian issues. For instance, you might use the SDL sized types (Uint8, Sint8) rather than char, which could have 8 or more bits.
You should take a good look at the Multiplayer & Networking Forum FAQ.
You should take a good look at the Multiplayer & Networking Forum FAQ.
Here's what you need to do.
Class User {
char fullmsg[50 + 255];
};
#define username(cls) cls.fullmsg
#define message(cls) (cls.fullmsg+50)
SDLNet_TCP_Send(sd, username.fullmsg, len)
Class User {
char fullmsg[50 + 255];
};
#define username(cls) cls.fullmsg
#define message(cls) (cls.fullmsg+50)
SDLNet_TCP_Send(sd, username.fullmsg, len)
That is a terrible suggestion. Do not do this, it is unnecessary and complex and a maintenance nightmare.
The only "upside" of it is avoiding sending the padding between the arrays, which I overlooked. This is especially important as padding can vary between compilers*. This can be solved by copying the data into a separate buffer (which you will almost certainly need to do anyway to handle partial send() between frames, or send() each array individually.
Remember that TCP is a streaming protocol and it doesn't matter if you were to send() each char individually, in random clusters of bytes or all together (although the TCP implementation might make better use of the network if you send as much data in one go). Your code at the receiving end must be capable of handling these cases, as they could occur when the OS is buffering your data into a single TCP frame or splitting your data into mulitple TCP frames.
* [size="1"]Technically, even the number of bits in a char can vary between compilers, but this won't happen on any major platform and would require such workarounds as to make it questionable whether it is reasonable to go to such effort unless you are targetting such a platform
The only "upside" of it is avoiding sending the padding between the arrays, which I overlooked. This is especially important as padding can vary between compilers*. This can be solved by copying the data into a separate buffer (which you will almost certainly need to do anyway to handle partial send() between frames, or send() each array individually.
Remember that TCP is a streaming protocol and it doesn't matter if you were to send() each char individually, in random clusters of bytes or all together (although the TCP implementation might make better use of the network if you send as much data in one go). Your code at the receiving end must be capable of handling these cases, as they could occur when the OS is buffering your data into a single TCP frame or splitting your data into mulitple TCP frames.
* [size="1"]Technically, even the number of bits in a char can vary between compilers, but this won't happen on any major platform and would require such workarounds as to make it questionable whether it is reasonable to go to such effort unless you are targetting such a platform
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement