Hi all…
Continuing to work with and go through the code & doc of SDL_net, I noticed
an incoherence between the docs and the actual code of SDL_net…
This is most noticable on the SDLNet_TCP_Recv page
http://jcatki.no-ip.org/SDL_net/SDL_net_23.html ), where you can read the
following line:—
Returns: the number of bytes received. If the number returned is less than
maxlen, then an error occured, or the remote host has closed the connection.
It seems like this is just not true. TCP is a reliable BYTE STREAM protocol,
but not a reliable PACKET protocol… Even though the bytes are guaranteed
to arrive and arrive in the order they were sent BUT
- one packet sent might arrive in several parts (that’s why what you said
is false)
- several small packets may arrive in a single “packet” (this caused the
problem I was talking about in my previous messages “Problem wh
SDLNet_TCP_Send (SDL_net)…” which is thus now resolved)
As for the rest of the docs, there are several places were this is
ambiguous… This can lead newbies like me to think that TCP is working wh
packets… Jonathan, I’d really be grateful if you could go through the docs
and correct this where need be…
As for SDL_net itself, I think (I’m just a newby in network programming)
it must be pretty common to work with packets in TCP, so I suggest adding
two new functions in SDL_net to do that… These functions would just have
to send the length of the packet along wh the actual data… Included is a
first draft of these functions “for win32”. If these are to be ever included
in SDL_net, someone should first make sure there is no endianess problem (I
think there is one) and write a Mac version of them.
See ya,
Ga?tan.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: packets.c
Type: application/octet-stream
Size: 1895 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020630/f752a3ac/attachment.obj
Ga?tan de Menten wrote:
This is most noticable on the SDLNet_TCP_Recv page
http://jcatki.no-ip.org/SDL_net/SDL_net_23.html ), where you can read
the following line:
Returns: the number of bytes received. If the number returned is less
than maxlen, then an error occured, or the remote host has closed the
connection.—
It seems like this is just not true. TCP is a reliable BYTE STREAM
protocol, but not a reliable PACKET protocol… Even though the bytes
are guaranteed to arrive and arrive in the order they were sent BUT
- one packet sent might arrive in several parts (that’s why what you
said is false)
int SDLNet_TCP_Recv(TCPsocket *sock, void *data, int maxlen)
sock This is a valid, connected, TCPsocket.
data This is a pointer to the buffer that receives the data from
sock.
maxlen This is the maximum length (in bytes) that will be read into
data.
this is correct. the function will not return before maxlen bytes have
been received, except the other side closes the socket.
- several small packets may arrive in a single “packet” (this caused
the problem I was talking about in my previous messages “Problem wh
SDLNet_TCP_Send (SDL_net)…” which is thus now resolved)
it does not matter, if the ip-packets get fragmented or repackt. the
kernel just waits for your buffer to fill and returns.
of course you can use non blocking io to overcome this.
As for SDL_net itself, I think (I’m just a newby in network
programming) it must be pretty common to work with packets in TCP, so
I suggest adding two new functions in SDL_net to do that… These
functions would just have to send the length of the packet along wh
the actual data… Included is a first draft of these functions “for
win32”. If these are to be ever included in SDL_net, someone should
first make sure there is no endianess problem (I think there is one)
and write a Mac version of them.
have a look at: http://thf.ath.cx under SNL. you are welcome to port SNL
to windows or mac. 
regards …
clemens
Ga?tan de Menten wrote:
- several small packets may arrive in a single “packet” (this
caused the problem I was talking about in my previous messages
"Problem wh SDLNet_TCP_Send (SDL_net)…" which is thus now
resolved)
it does not matter, if the ip-packets get fragmented or repackt. the
kernel just waits for your buffer to fill and returns.
Is it just on windows or is it just my computer? But here, it doesn’t
wait for the packet to be full to return, although I didn’t specify
anything special.
It does wait for some data to be received. So I guess this is called
"blocking"…
okok, i shouldn’t write emails, when i’m half asleep. i just double
checked (with a small program) and you are completly right. i think i
have just confused something i even don’t remember quite now. 
read() may return before it has received a maximum number of bytes, and
on linux it seems as there are more then one reason for this. a full TCP
packet has benn received, the other side closed the connection or the
read was interrupted by a signal.
i hope i didn’t confuse anybody.
best regards …
clemens
ok, so I see where the docs are wrong now…
It makes the explaination in the docs much more complicated 
but they do need to be corrected…I’ll see if I can do that and still make them easily understandable 
if anyone wants to try and rewrite that paragraph about the return codes, be my guest!–
-==-
Jon Atkins
http://jonatkins.org/
The SDL_net docs have been updated, and hopefully now reflect the true nature of how the TCP receive functionality works.
there’s still a good question as to whether the SDL_net SDLNet_TCP_Recv implementation can hold up to all the possible interrupts and signals and such…
hopefully it just returns a -1 in all “odd” cases…even though that is not optimal perhaps…since we’d want it to recover if possible.
otherwise people will get partial packets, or other nonsense where they end up thinking the socket is invalid and that they should disconnect.
perhaps even SDL_mixer and SDL_net might have problems if used together…I dunno.–
-==-
Jon Atkins
http://jonatkins.org/
perhaps even SDL_mixer and SDL_net might have problems if used together…I dunno.
No, they won’t.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Sam Lantinga wrote:
perhaps even SDL_mixer and SDL_net might have problems if used together…I dunno.
No, they won’t.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
I was being overly paranoid, I knew by now we’d know if there was any problems :)–
-==-
Jon Atkins
http://jonatkins.org/