Messages

1

Network / Re: Dropping TCP packets

« on: May 08, 2011, 06:22:29 am »

I think I might know the problem.  According to some internet notes, the recv() method will return -1 if you try to read a packet on a NON-BLOCKING socket when there is nothing to be read.  This will in turn cause the Socket class to return an Error status to the parent method call which will then abort the reading of the packet right then and there.

So what is the answer you might be asking?  It appears that the internet suggests using the "select" call to wait for the socket to be ready before performing the Read operation.  I would suggest you try looking at the "Select" tutorial and use the Socket.Wait(timeout) method before performing the Socket.Receive method to get the packet, otherwise your NON-BLOCKING connection might get half-way through reading the packet and run out of bytes and return without giving you the full packet.  This might be a bug in the way the SFML TCP Socket class handles NON-BLOCKING Receives, we may want to investigate a little more into the Receive method and determine what if anything can be done to make the Receive(Packet) method more robust when the socket is NON-BLOCKING.

Please let me know if you have any questions and good luck!

Thanks a lot!
I finally solved it, it actually turned out to be a quite silly mistake.

Code: [Select]


sf::SocketTCP sock = (*it).socket;

sock should be a reference, so this solved the problem

Code: [Select]


sf::SocketTCP &sock = (*it).socket;

I was making copies of the socket every frame.

Thank you for your help!

2

Network / Re: Dropping TCP packets

« on: May 08, 2011, 02:30:16 am »

Would it be possible to post the relevant code where these packets are created and where they are processed?

Sure!

This is where the packet is created. This is done every frame.

Code: [Select]


if (timer.GetElapsedTime() >= 0.01f))
{
timer.Reset();
Input input(GetInput());
if (input != lastInput)
{
sf::Packet packet;
packet << PacketTypeValue(PT_INPUT);
packet << input;

socket.Send(packet);

lastInput = input;
}
}


This method is also called every frame

Code: [Select]


void NetworkManager::Update()
{
sf::Packet packet;

for (ClientList::iterator it = clients.begin(); it != clients.end(); ++it)
{
sf::SocketTCP sock = (*it).socket;
sf::Socket::Status status = sock.Receive(packet);
if (status == sf::Socket::Disconnected)
{
Disconnect(*it);
}
else if (status == sf::Socket::Done)
{
PacketTypeValue pt;
packet >> pt;

if (pt == PT_INPUT)
{
packet >> (*it).input;
}
}
}
}


3

Network / Re: Dropping TCP packets

« on: May 08, 2011, 12:54:36 am »

Not knowing a lot about your code I can only offer the following ideas:

- The connection was accidentally closed (unlikely if your only missing a few packets, likely if your missing a series of packets in a row)
- The packets were received in the wrong order (TCP tries to make sure that all packets are received in the right order)
- The packets being sent were larger than 1472 bytes in size and therefore were split into multiple smaller packets, but some of these smaller packets were lost.  This might explain the loss, but TCP is suppose to resend the packets if some were lost in transmission.
- The packets were dropped because your TCP buffer is FULL.  This can happen if your sending the packets faster than the other end can process them.  The operating system helps by buffering the packets up to a certain point, but after that there is no buffers available and the packets might get dropped.  Try to see if you can compute (with wireshark) how fast the packets are being sent and see if you can add some delay to your sender and see if your packets stop getting dropped.
- Some other issue that I don't know.

Ryan Lindeman

Thank you for your answer.

I am sending a packet every time I press or release a button on the keyboard. That's the only traffic going between the client and the server. But some of the packets still get lost even over localhost.

4

Network / TCP dropping packets?

« on: May 07, 2011, 12:19:57 am »

Hi!

I'm using non-blocking TCP sockets, which I call Receive() on every frame. They seem to be dropping packets quite often, even when I'm running both the server and the client on the same machine.

I've checked with Wireshark and the server computer is receiving the packets but the application doesn't receive them for some reason.

Anyone got any idea?

5

General / SFML doesn't work!

« on: October 26, 2008, 07:02:45 pm »

Did you install the latest version of your OpenGL drivers ? Which graphics card do you have ?

I have a NVIDIA card and I have the very latest version of the NVIDIA drivers.

EDIT:
If it is any help, all the samples that crashes, crashes with return code 1.

6

General / SFML doesn't work!

« on: October 26, 2008, 04:34:38 pm »

Did you try recompiling SFML ?

Yes, I did.
But I got compiling errors when I compiled my program using the recompiled SFML. It said something about undefined references from opengl and some other libraries, but when I included those libraries and it compiled I was back to the original problem.

7

General / SFML doesn't work!

« on: October 24, 2008, 03:01:39 pm »

The only thing I can think of right now is broken OpenGL drivers.

This would only break examples using the graphics package. Are sound and network samples working ?

I don't know, I'll check...

EDIT:
The sound package and network package works fine.
The graphics package and/or the window package crashes.

I use Windows Vista Ultimate

64 bits ? If so, you need to recompile SFML because all precompiled binaries are for 32 bits architectures.

I use the 32-bit version.

8

General / SFML doesn't work!

« on: October 24, 2008, 02:30:02 am »

Hi!

I have a huge problem, SFML doesn't work for me, at all.
All the examples plus all of the programs I've downloaded which use SFML just immediately crashes with the regular "this program has stopped working...".

When I launch my own SFML programs then only the window-decoration shows up with no content whatsoever.

I use Windows Vista Ultimate, I've looked all over for someone with a similar problem, but I can't find anyone.

The only thing I can think of right now is broken OpenGL drivers.