sf::Socket::Error when reading into a buffer too small

[Floomi]

I have an SFML 1.6 non-blocking UDP socket which I am receiving raw data from. As per the example in the tutorial I am calling Skt.Receive(), passing in a buffer to fill. When the buffer is too small to fit the data, Receive() returns sf::Socket::Error.

Unfortunately I appear to have no way of distinguishing this (easily rectified!) error from more serious errors that may have occurred. WSAGetLastError() on Win32 returns a specific error code WSAEMSGSIZE when the buffer is too small, and a little research shows *nix puts EMSGSIZE in the errno variable to indicate the same issue. However, checking these rather defeats the point of using SFML for cross-platform compatibility.

So, in an attempt to do things "the SFML way": is there a way I can peek at the top message in the socket's recv buffer to determine how long it is? Or a way to get the socket to truncate the message and return the data up to the size I passed in (as the standard implementation of recvfrom() does)?

I could simply allocate an array of size 65516 (the maximum amount of data you can fit into an IP packet), but that's a really poor workaround.

Any tips, or should I break out the #ifdefs and write my own error lookups to catch this situation?

edit:\ Just noticed a similar thread here - I guess I'm doing it myself.

[Floomi]

I've done a little experimentation and it turns out that while you do get sf::Socket::Error, it also discards the message and the next call to Receive() will give you the next message. For some reason I thought it would get "stuck" attempting to read the same data into the buffer repeatedly, which was the cause of my frustration. So for my purposes I can simply set the buffer to be the maximum size of any valid message I expect to receive and anything bigger than that automatically gets thrown away.

However, there still remains the issue of not being able to tell it apart from a more "serious" error. I don't think it's right to treat "someone sent a malformed packet" the same as "the connection has been forcibly terminated".

[Laurent]

However, there still remains the issue of not being able to tell it apart from a more "serious" error. I don't think it's right to treat "someone sent a malformed packet" the same as "the connection has been forcibly terminated".

Disconnection is a separate error (sf::Socket::Disconnected), and cannot happen with UDP.
But anyway to me it's not an issue, unless you can find a meaningful situation where one would need to tell the difference between "buffer too small" and other errors. I can't find one, because it results in the data being lost anyway and there's nothing you can do about it, whether it is this particular error or another.

[Floomi]

I guess it depends on the range of errors covered by sf::Socket::Error. If they're all recoverable and result in the loss of the packet, but don't have any further consequences (like the socket being closed), then I guess it's fine.

[Laurent]

I haven't tested every single potential error, but the behaviour should be the same for everything that is covered sf::Socket::Error, yes.