How to know when SDLNet_TCP_Recv has no more data available, or how to specify timeout for it?

Yeah, is there a way to specify a timeout for SDLNet_TCP_Recv, or how to
know when there’s no more data, so SDLNet_TCP_Recv doesn’t stay waiting for
data to arrive? I’m thinking in using SDL threads, but I’m still not sure
how do I apply them in my case…

I’ve also tried to search in google but I haven’t found any info about
applying a timeout either by SDL_Net or by threads…

Any help is greatly appreciated! :smiley:

  • DARKGuy

It’s my understanding that most would use something like:
if (SDLNet_TCP_Recv(sd, (char*)buffer, 512)) so in your main loop you check to see if there is something to pick up and the answer is yes or no. You do have the choice not to check or to close out that sd. Is this what you mean by waiting?

---- “DARKGuy .” <dark.guy.2008 at gmail.com> wrote:> Yeah, is there a way to specify a timeout for SDLNet_TCP_Recv, or how to

know when there’s no more data, so SDLNet_TCP_Recv doesn’t stay waiting for
data to arrive? I’m thinking in using SDL threads, but I’m still not sure
how do I apply them in my case…

I’ve also tried to search in google but I haven’t found any info about
applying a timeout either by SDL_Net or by threads…

Any help is greatly appreciated! :smiley:

  • DARKGuy

How about checking if there is data available before calling
SDLNet_TCP_Recv. Try creating a SDLNet_SocketSet and using the
functions SDLNet_CheckSockets and SDLNet_SocketReady.On 08/10/2007, DARKGuy . <dark.guy.2008 at gmail.com> wrote:

Yeah, is there a way to specify a timeout for SDLNet_TCP_Recv, or how to
know when there’s no more data, so SDLNet_TCP_Recv doesn’t stay waiting for
data to arrive? I’m thinking in using SDL threads, but I’m still not sure
how do I apply them in my case…

I’ve also tried to search in google but I haven’t found any info about
applying a timeout either by SDL_Net or by threads…

Any help is greatly appreciated! :smiley:

  • DARKGuy

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

What I have done is send the number of bytes before hand. The receiver then
knows how many bytes to expect. For example, the sender transmits a single
integer (the number of bytes for the payload) which is expected by the
receiver. The receiver gets the integer and uses that value to receive
exactly those number of bytes for the second transmission (e.g. the payload).

Another solution could be to have the receiver read one byte at a time. The
sender would then send a control byte (of some kind) to indicate the end of
the transmission.

AlvinOn 08/10/2007, DARKGuy . <dark.guy.2008 at gmail.com> wrote:

Yeah, is there a way to specify a timeout for SDLNet_TCP_Recv, or how to
know when there’s no more data, so SDLNet_TCP_Recv doesn’t stay waiting
for data to arrive? I’m thinking in using SDL threads, but I’m still not
sure how do I apply them in my case…

I’ve also tried to search in google but I haven’t found any info about
applying a timeout either by SDL_Net or by threads…

Any help is greatly appreciated! :smiley:

  • DARKGuy

First of all thanks for answering guys :slight_smile:

for Alvin:
That would work if I was working on the server program, but I’m just making
a chat client for the Battle.net protocol, similar to TopazChat but
multiplatform thanks to wxWidgets, since WINE has small issues with
emulating TopazChat… mainly slowdowns and such… since I can’t edit the
server itself (duh :P) I’m stuck to make something generic.

for Brian:
Yup! I tried that yesterday when Walk from #sdl suggested it to me, it kinda
worked as expected, so we can say the issue is a bit resolved…

However, could any of you, if possible, make some example client program
that uses the SocketSets ? I’ve seen server examples in a wiki… dunno if
it was GPWiki or SDL wiki because I’m typing this at work and I can’t recall
correctly, but I never saw any client example using SocketSets… I’d be
really glad if any of you could make one of those, since I learn better by
code rather than theory… xD… it’d also help others :).

Thanks for answering :smiley:

  • DARKGuyOn 10/8/07, Alvin wrote:

On 08/10/2007, DARKGuy . <@DARKGuy> wrote:

Yeah, is there a way to specify a timeout for SDLNet_TCP_Recv, or how to
know when there’s no more data, so SDLNet_TCP_Recv doesn’t stay waiting
for data to arrive? I’m thinking in using SDL threads, but I’m still not
sure how do I apply them in my case…

I’ve also tried to search in google but I haven’t found any info about
applying a timeout either by SDL_Net or by threads…

Any help is greatly appreciated! :smiley:

  • DARKGuy

What I have done is send the number of bytes before hand. The receiver
then
knows how many bytes to expect. For example, the sender transmits a single
integer (the number of bytes for the payload) which is expected by the
receiver. The receiver gets the integer and uses that value to receive
exactly those number of bytes for the second transmission (e.g. the
payload).

Another solution could be to have the receiver read one byte at a time.
The
sender would then send a control byte (of some kind) to indicate the end
of
the transmission.

Alvin


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

What I have done is send the number of bytes before hand. The receiver then
knows how many bytes to expect. For example, the sender transmits a single
integer (the number of bytes for the payload) which is expected by the
receiver. The receiver gets the integer and uses that value to receive
exactly those number of bytes for the second transmission (e.g. the payload).

This only works, of course, for protocols you invent yourself.

Another solution could be to have the receiver read one byte at a time. The
sender would then send a control byte (of some kind) to indicate the end of
the transmission.

I have to imagine that’s really inefficient.

We use SDL_Net currently, but we go behind its back and make the sockets
non-blocking in an ugly, platform specific way. I’m surprised no one here
has responded with the stock “Use threads” response–but non-blocking
reads are far easier and not much more inefficient than setting up a whole
thread system.

The answer to the original question is, you can’t, really :frowning:

GregoryOn Mon, 8 Oct 2007, Alvin wrote:

What about threads? :frowning: I wouldn’t mind to make some SDL_Threads…On 10/8/07, Gregory Smith wrote:

On Mon, 8 Oct 2007, Alvin wrote:

What I have done is send the number of bytes before hand. The receiver
then
knows how many bytes to expect. For example, the sender transmits a
single
integer (the number of bytes for the payload) which is expected by the
receiver. The receiver gets the integer and uses that value to receive
exactly those number of bytes for the second transmission (e.g. the
payload).

This only works, of course, for protocols you invent yourself.

Another solution could be to have the receiver read one byte at a time.
The
sender would then send a control byte (of some kind) to indicate the end
of
the transmission.

I have to imagine that’s really inefficient.

We use SDL_Net currently, but we go behind its back and make the sockets
non-blocking in an ugly, platform specific way. I’m surprised no one here
has responded with the stock “Use threads” response–but non-blocking
reads are far easier and not much more inefficient than setting up a whole
thread system.

The answer to the original question is, you can’t, really :frowning:

Gregory


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[…]

What I have done is send the number of bytes before hand. The
receiver then knows how many bytes to expect.
[…]
This only works, of course, for protocols you invent yourself.

Another problem is that you’re still using a blocking call, which
means any network delays in the middle of a “packet” will stall your
application anyway.

Another solution could be to have the receiver read one byte at a
time. The sender would then send a control byte (of some kind) to
indicate the end of the transmission.

I have to imagine that’s really inefficient.

Probably not all that bad with a low volume protocol on a modern PC
running a serious OS, but still not recommended.

[…]

I’m surprised no one here has responded with the stock "Use threads"
response–

Ok then; why not do the network I/O in a dedicated thread? :wink:

Well, there is one good reason to avoid that method, although it
really is the proper way of doing it: Complexity. Whether you’re just
wrapping the calls to avoid blocking, or you’re doing some real work
(ie decoding, preparing “requests” for the game logic etc) in that
thread as well, there has to be communication with other threads
sooner or later, and that’s where things tend to get a bit hairy.

Why not try Bob Pendleton’s event based NET2 layer? Nice, efficient
and easy to use. You get a proper solution without having to worry
about your own code running in concurrent threads.
http://gameprogrammer.com/net2/net2-1.html

but non-blocking reads are far easier and not much more inefficient
than setting up a whole thread system.

I suppose “efficient” is a relative term… :slight_smile:

If an application (a game server, maybe?) ends up doing a lot of
polling in relation to the amount of real work done, it’ll waste
quite a bit of CPU time doing pointless syscalls. It gets worse with
more dense traffic, higher “poll rates” (ie game frame rate) - and
what do you do if the application has no natural heart beat (such as
a video frame rate) to drive the polling?

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Monday 08 October 2007, Gregory Smith wrote: