Max Packet Size?

[KageJittai]

Is there a way we can block sending packets of certain sizes.  Since the sf::Packet uses a int32 size header, it can support packets upto 4gigs... but I don't want this to lead to abuse of my server's bandwidth and memory, and such.

[Laurent]

Sure, you can simply check the packet size before adding new data.

[Tank]

This will work for sending packets, but not receiving them. Sending is indeed not critical because you have control over what goes out and what not. However receiving a packet can't be controlled, because SFML relies on the packet length sent by the peer and starts to receive data until the buffer is filled, without the possibility to abort it.

So servers using sf::Packet for receiving data can be fairly easy DDoSed. Just sent data beginning with 0xffffffff and thereafter pure garbage. Do that some times in parallel and you'll soon get the server's RAM really dirty.

An accessor for checking how much data has been already received in myPendingPacket would be nice. If it exceeds a certain value, one can disconnect the peer (limiting packet sizes by just stopping receiving is no option, the data was sent nevertheless).

[Laurent]

An accessor for checking how much data has been already received in myPendingPacket would be nice.

sf::Packet is not made for safety, and there are many ways to crash a server using them, if someone really wants to.
So we'd need much more than an accessor to the current received size

[Tank]

What issues are you talking about except the flooding?

[Laurent]

sf::Packet uses a fixed protocol. So basically if you send random data (not following the protocol) your server may begin to have an undefined behaviour.

I'm not an expert in network hacking, but I'm sure there are more ways to break a server with sf::Packet. If I remember correctly, this topic has already been discusses before on the forum.

[KageJittai]

Well... a lot of the security would be input validation after sf::Packet.  But you could probably do some pretty nasty things though the sf::Packet layer.   For example what if you sent a normal size packet that was to read as a string, but for the string length exceeded the end of the packet?

[KageJittai]

Hmmm looking at the sf::Packet code, it checks for that a string length is shorter or equal to remaining amount of packet.   So I guess this is safe.  The only real issue I could see is infact sending a bogus packet length

[Tank]

You can always send random garbage to a server. The trick is to drop what doesn't make sense. I think the sf::Packet protocol is useful and easy. And when extracting data from sf::Packet, you can check if everything's there and if it's valid (application protocol). Don't see any problems here.

The packet length field could be lowered, but that highly depends on the application. For my cases, a maximum size of a word has always been enough (65 KiB per packet). The result is 2 bytes (for strings +2 bytes per string) less traffic, however the question is what the enduser really needs. I know that it's very specific, but is there a chance to control some aspects of the protocol, like length field size?

[Ceylo]

I remember I had modified sf::Packet and sf::TCP/UDPSocket in order to add some features such as:
- check whether a socket is in blocking mode
- set a packet size limit
- check for how long the packet has not received data (to do some timeout check)

You can find these here : http://yalir.svn.sourceforge.net/viewvc/yalir/Dependencies/sfml2/

Note that the modifications were done on the SFML 2.x version provided at that time, thus it's not really up to date. I believe you can still apply my changes to the current SFML 2.x sources though.

If that can be of any help.