TCP Lag Reduction Techniques?

[Jungletoe]

What do you mean by "corrupts the packets"? If you mean data corruption, how do you determine this? Did you check whether this corresponds to what the server is sending?

As for the receive not working, it might also be the client code that is not sending/functioning properly. If you want to make robust software that functions even over bad connections, you need to make sure that both sides are able to handle such a scenario.

Maybe you could show the client send and receive code as well.

Ok. Here is the client receive code (it is multi threaded and blocking still since I haven't had any problems with it).

while(running)
        {
                while(gl::Vars::connected)
                {
                        sf::Packet pack;
                        socket.receive(pack);

                        gl::mutex.lock();
                        sf::Int32 packetType;           //      Determines what the packet contains, different packet types contain different info

                        if(pack >> packetType)
                        {
                                       /*
                                                      HANDLE PACKETS

                                        */
            }

                        else
                        {
                                std::cout << "Junk Packet";
                        }

                        gl::mutex.unlock();
                        sf::sleep(sf::milliseconds(10));
                }
                sf::sleep(sf::seconds(.1));
        }
}
 

I really don't think this is a client sided issue since it was receiving the packets correctly before I changed it all around.

By the way, I also simplified the server sends:

void Connector::sendPacket(sf::Packet* spack)
{
        if(packets.size() <= 0)
        {
                sf::Socket::Status status = socket.send(*spack);

                if(status == sf::Socket::NotReady)
                {
                        packets.push(*spack);
                }
        }

        else
        {
                packets.push(*spack);
        }
}
 

void NetworkManager::retryDroppedPackets()
{
        for(sf::Int32 i = 0; i < ent::connectors.size(); i++)
        {
                if(ent::connectors[i]->packets.size() > 0)
                {
                        sf::Socket::Status status = ent::connectors[i]->socket.send(ent::connectors[i]->packets.front());

                        if(status != sf::Socket::NotReady)
                        {
                                ent::connectors[i]->packets.pop();
                        }
                }
        }
}
 

[binary1248]

You should handle the case that send() returns sf::Socket::Error as well. TCP does not complain about little things that can be corrected over time so whenever an error really occurs you should take it seriously and try to resolve it. It is different from sf::Socket::Disconnected, sf::Socket::NotReady or sf::Socket::Done in that it indicates something that is not supposed to happen, even over bad connections. Like I said before, if TCP determines that it doesn't have a possibility to recover from errors, it will RST the connection and you will get sf::Socket::Disconnected back from SFML, not sf::Socket::Error.

I see that in your client code, you don't handle the return value of the receive(). Even if the client code works for now, adding some sort of handling or logging for the case that errors might happen will save you a lot of headaches in the future.

[Jungletoe]

You should handle the case that send() returns sf::Socket::Error as well. TCP does not complain about little things that can be corrected over time so whenever an error really occurs you should take it seriously and try to resolve it.

How do I "resolve it" exactly?

[binary1248]

Check if sf::Socket::Error is returned. If you are indeed getting socket errors, you can check what kind of errors you are getting using the operating system specific function WSAGetLastError() in Windows or checking errno in Linux.

[Jungletoe]

Check if sf::Socket::Error is returned. If you are indeed getting socket errors, you can check what kind of errors you are getting using the operating system specific function WSAGetLastError() in Windows or checking errno in Linux.

Oh ok. Thank you! I think it was actually a client issue, because after I switched that client recv() function around, nobody has crashed yet (I have my fingers crossed).

[Jungletoe]

Yeah, people are still getting deformed packets. I still can't test them since it only happens with people who have bad connections. The client nor the server is returning any errors on receive.

EDIT:
It seems to be because the client is now getting deadlocked. Is it even possible to have a single threaded client with a loading screen and all?

Client send code:

void NetworkManager::sendPacket(sf::Packet* pack)
{
        if(gl::Vars::connected)
        {
                socket.send(*pack);
                delete pack;
        }
}
 

[The Terminator]

I can't really help you on the networking stuff, but I would recommend avoiding raw pointers that you use. A lot of memory problems can arise from using that, and switching everything from things like

sf::Packet* packet

to

std::unique_ptr<Packet> packet

Isn't hard
Don't forget to use std::move

[binary1248]

It is always possible to do things in a single thread. After all, on single core CPUs there is only one execution context and the operating system just "pretends" that multiple threads can run "simultaneously".

If you want your client to be single threaded, all you have to do is make sure that you use polling and make all socket/file access asynchronous (non-blocking). That way you just have to initiate them and periodically check if the operation has been completed. That way you will never have to block on anything. Some things however cannot be done asynchronously, such as database access in some cases. In those cases you have no other choice than to thread the access itself and transform it into an asynchronous operation for the rest of your application to use.

[Jesper Juhl]

I know this is an old thread, but I think I have something useful to add for future readers, so here goes.

Reducing lag is often a matter of reducing latency, so on TCP sockets you often want to disable Nagle's algorithm. You can do this with the setsockopt() function and the TCP_NODELAY option.

[Laurent]

https://github.com/SFML/SFML/blob/master/src/SFML/Network/Socket.cpp#L106

[Jesper Juhl]

Ohh. Thanks Laurent. I guess I should have checked the code first