"Endless"-getting-messages problem

[EiTkoCaT]

Hey,

so I have this connections I want to get from them always messages and just write them. The thing is that I'm talking about 20 TCP messages per second per client. And there gonna be a lot of clients.

Any way, I have a problem... With my 1 client connected, it's drops me an error in the 3rd message I send. My code is maybe weird, that's right - but that's how I thought. So every time the client sends something like:
3TR 1 name var1 var2\0
and I need the server to split the string every " " so I use string to vector split by boost. Here's my full code:

Code: [Select]

while (CountinewWithPlayer)
{

std::size_t Receiveda = 0;
sf::Socket::Status status;
char MessageLivea[256];
status = (Client.Receive(MessageLivea, sizeof(MessageLivea), Receiveda));
if ( status  == sf::Socket::Disconnected || status  == sf::Socket::Error)
{
cout << "Disconnected" << connectedClients << endl;
CountinewWithPlayer = 0;
} else if ( status  == sf::Socket::Done )
{
cout << MessageLivea << endl;
std::vector<std::string> current_stringLivea;
boost::split(current_stringLivea, MessageLivea, boost::is_any_of(" "));
cout << current_stringLivea[0] << current_stringLivea[1] << current_stringLivea[2] << current_stringLivea[3] << endl;
}
}

My problem:

Debug Assertion Failed!
 
Program: …
File: c:\program files (x86)\microsoft visual studio 10.0\vc\include\vector
Line: 932
 
Expression: vector subscript out of range
 
For information on how your program can cause an assertion
Failure, see the Visual C++ documentation on asserts.

What to do?
Thanks.

[Laurent]

Obviously your vector has less then 4 elements. So either you're using boost::split wrong, or you didn't receive "3TR 1 name var1 var2".

Don't forget that TCP is a stream protocol, sending 1 block of N bytes doesn't mean that you will receive 1 block of N bytes -- it can be X blocks of N/X bytes. If you want to ensure a 1:1 communication, use sf::Packet.

[EiTkoCaT]

I've found the problem, it was because of nagle, so I disabled it in the client but now I have to disable it in the server also. (http://www.sfml-dev.org/forum/viewtopic.php?p=32128#32128)

[Laurent]

This is not a reliable solution. You can't assume that one TCP send will always be equal to one TCP receive. Even with Nagle algorithm disabled.

The only way to handle packets is to insert explicit bounds, which is exactly what sf::Packet does.

[EiTkoCaT]

I tested it and it seems to work.. All the clients using exactly the same platform... Also the client is not SFML so I can't really use it, can I?

[Laurent]

I tested it and it seems to work..

Sure it will work most of the time. But it's not 100% reliable.

Also the client is not SFML so I can't really use it, can I?

True, you can't use sf::Packet (at least directly). But anyway you should use the kind of solution that I described.

[EiTkoCaT]

I gotta say big thank for the help.

I'm not sure how to insert that explicit bounds thing. You mean like doing messages like:
first:3EW second:8wewe third:6464 fourth:445

and than in the other side just to check every time that the current (first, second, third, etc) is like that?

Thanks!!!

[Laurent]

There are two ways:
- send the size of the packet first
- put a special sequence of bytes at the beginning and end of a packet

[EiTkoCaT]

OK thanks! I will do it.
Just a question: if it's not fit just ignore the packet?

Thanks.

[Laurent]

Just a question: if it's not fit just ignore the packet?

Sorry I don't get it, what do you mean?

[EiTkoCaT]

If the size of the packet I send is not the same of the packet size received, just ignore the packet?

[Laurent]

No. Like I said, TCP is not a "packet" protocol (unlike UDP), it's a "stream" protocol. Which means that it doesn't matter how many times you call send(), it's the protocol implementation that chooses how the data will be split on the other end. Some "packets" may be merged, some may be split, you can't expect anything.

So... the purpose of sending the size is to know where your packet ends, and when the next one starts. After receiving data, you must recompose the packets according to their size.

[EiTkoCaT]

OK I think I got that.. I'll try and if I'll have problems I'll notify here.

Thanks!