Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML 2.0 TCP reliability question (SOLVED)  (Read 3403 times)

0 Members and 1 Guest are viewing this topic.

fredrick

  • Newbie
  • *
  • Posts: 20
    • View Profile
SFML 2.0 TCP reliability question (SOLVED)
« on: December 28, 2011, 12:40:21 pm »
It has been a while since i last gave SFML networking a try, i wanted to give it a go after using other API's (Qt Networking\Boost::Asio)

There is a few things i don't understand, let me give a few examples.

Packet sizes:

Sending a sample with 999 bytes, to a receiver (server) reads the size of the data randomly, either less than 999 bytes (still within MTU!) or strangely more often with more data than i specified...

Code of sender....

Code: [Select]
sf::TcpSocket socket;
if (socket.Connect("localhost", 25001) == sf::TcpSocket::Done) {
printf("Connected to server\n");

char packet[1024] = "";
for (int i = 0; i < 100; i++) {
memset(packet, 0x01, 999);
if (sf::TcpSocket::Done == socket.Send(packet, 999)) {
printf("Packet sent to server\n");
}
else {
printf("Failed to send packet to server\n");
}
}

}
else {
printf("Failed to connect to server\n");
}



Code of receiver:


Code: [Select]
while (true) {
size_t receivedSize = 0;
sf::TcpSocket::Status status = clientSocket->Receive(packet, sizeof(packet), receivedSize);
if (status == sf::TcpSocket::Done) {
handleClientPacket(packet, receivedSize);
}
else if (status == sf::TcpSocket::Error ||
status == sf::TcpSocket::Disconnected) {
printf("Packet error or disconnection\n");
break;
}
else {
// Not yet ready
sf::Sleep(10);
}
}

Code: [Select]

void Server::handleClientPacket(const char *data, size_t size)
{
printf("Packet %d with size %u\n", m_packetCount++, size);
}



results:

...
Packet 34 with size 999
Packet 35 with size 999
Packet 36 with size 999
Packet 37 with size 999
Packet 38 with size 999
Packet 39 with size 999
Packet 40 with size 999
Packet 41 with size 999
Packet 42 with size 999
Packet 43 with size 999
Packet 44 with size 999
Packet 45 with size 999
Packet 46 with size 999
Packet 47 with size 1024
Packet 48 with size 1024
Packet 49 with size 1024
Packet 50 with size 1024
Packet 51 with size 1024
Packet 52 with size 1024
Packet 53 with size 1024
Packet 54 with size 1024
Packet 55 with size 1024
Packet 56 with size 1024
Packet 57 with size 1024
Packet 58 with size 1024
Packet 59 with size 1024
Packet 60 with size 1024
Packet 61 with size 1024
Packet 62 with size 624
Packet 63 with size 999
Packet 64 with size 999
Packet 65 with size 999
Packet 66 with size 999
Packet 67 with size 1024


etc... very strange, my questions is why? I expected 999.. yes OS socket buffer was filled up at some point, i want to know why the socket wrote more than what i specified...


I have a few other remarks but lets start with this one..

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFML 2.0 TCP reliability question (SOLVED)
« Reply #1 on: December 28, 2011, 12:49:07 pm »
TCP is a stream protocol, the number and size of received packets can be very different from the number and size of sent packets. It's the lower protocol/network layers that decide how to group/split data.

If you want 1:1 packet transmission, use sf::Packet.
Laurent Gomila - SFML developer

fredrick

  • Newbie
  • *
  • Posts: 20
    • View Profile
SFML 2.0 TCP reliability question (SOLVED)
« Reply #2 on: December 28, 2011, 01:26:52 pm »
Why would we care about getting the size of data on the lower part of the protocol, all i care about is the size of the payload.

Edit:

Also whats the point using TCP if i cant rebuild the same data on the receiving end as compared to the sending end?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFML 2.0 TCP reliability question (SOLVED)
« Reply #3 on: December 28, 2011, 02:55:16 pm »
Quote
Why would we care about getting the size of data on the lower part of the protocol, all i care about is the size of the payload.

TCP can split packets and doesn't recompose them when they arrive. That's how the protocol is defined, it's not SFML's fault.

Quote
Also whats the point using TCP if i cant rebuild the same data on the receiving end as compared to the sending end?

You receive the same data, but not grouped the same way as you sent it. If you want to preserve packets boundaries, use sf::Packet.

You should read more about how TCP works, it's important to understand it in order to use it efficiently and safely.

And, by the way, you should have the same issues with the other network library that you mention.
Laurent Gomila - SFML developer

fredrick

  • Newbie
  • *
  • Posts: 20
    • View Profile
SFML 2.0 TCP reliability question (SOLVED)
« Reply #4 on: December 28, 2011, 03:35:09 pm »
No i don't have had any issues with those other libraries, but they may be grouping them for me.

One thing i liked with Qt was that the "send" function return how much was written (or buffered) on the socket, i guess each time SFML returns DONE it is done but there must be cases where it skips whole chunks when it returns not done and i have to re-send it or does it buffer it for me perhaps.

And yes i have things to read up on regarding TCP, thanks for taking time to answering my questions  :wink:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFML 2.0 TCP reliability question (SOLVED)
« Reply #5 on: December 28, 2011, 04:00:40 pm »
Quote
No i don't have had any issues with those other libraries, but they may be grouping them for me.

If you use their lowest-level functions, they shouldn't.

Quote
One thing i liked with Qt was that the "send" function return how much was written (or buffered) on the socket, i guess each time SFML returns DONE it is done but there must be cases where it skips whole chunks when it returns not done and i have to re-send it or does it buffer it for me perhaps.

TcpSocket::Send loops until everything has been sent, or an error occured. So basically you just have to call it once, and after it returns either everything was sent or it failed.
Laurent Gomila - SFML developer

fredrick

  • Newbie
  • *
  • Posts: 20
    • View Profile
SFML 2.0 TCP reliability question (SOLVED)
« Reply #6 on: December 28, 2011, 06:18:47 pm »
ok thanks for the clarification