-1

Is it a good idea to ALWAYS use either select() or poll() and impose say a 10 second timeout on both send() and recv() calls? Or should I just allow them to block indefinitely?

Does imposing this sort of timeout (using select() or poll()) lead me to lose some sort of error reporting or functionality (in the form of return values) that I can get when just using send() and recv()?

NOTE : Assuming I poll in the same thread right before I call recv() or send(). And the call to poll() is statically well formatted, i.e. The parameters dont change dynamically besides how they do based on the invocation of the wrapped recv() or send()

ANOTHER NOTE : If there is a timeout, then I will throw an exception and let the programmer catch it. I was hoping this would lead to protection against a DOS attack. If there is indeed a timeout. I will throw an exception and not get to calling either recv() or send()

YET ANOTHER NOTE : Source code related to what I am talking about can be found here https://beej.us/guide/bgnet/output/html/singlepage/bgnet.html#faq under a similar FAQ

Thanks!

Curious
  • 20,870
  • 8
  • 61
  • 146
  • 1
    What exactly are you trying to solve? What will you do if there is a time-out? Start polling again? Or exit? Or something else? What do you expect to do if there is some other error? What do you want to have happen if the receiving side is really on a "go slow" and the message is getting there, but very slowly (someone replaced a fast link with a much slower one, for example)? – Mats Petersson Dec 30 '15 at 14:31
  • 1
    Can you provide some code? – Dieter Meemken Dec 30 '15 at 14:32
  • DOS attacks are typically "lots of traffic", not "no traffic", which is what gives a timeout... – Mats Petersson Dec 30 '15 at 14:36
  • I edited my question above! Sorry for not being clear enough the first time.. – Curious Dec 30 '15 at 14:37
  • @MatsPetersson Yep you are correct! But the type of attack I had in mind was when I wait on recv() when I should logically be getting more data because the request so far is incomplete and the attacker just sits there not sending any data. – Curious Dec 30 '15 at 14:43

4 Answers4

1

What are you going to do after timeout lapses? If you are going to start waiting again, than timeout gives you nothing.

If you will close the connection and brand it dead, than timeout is very useful.

SergeyA
  • 61,605
  • 5
  • 78
  • 137
  • If I am planning on throwing an exception saying that a timeout has happened is it a good idea? – Curious Dec 30 '15 at 18:58
  • @Curious, I have no idea. Is it a good idea in your application? Is timeout an exceptional case where you absolutely can't tolerate it at the call site, nor you can sanely propagate the error upstream? – SergeyA Dec 30 '15 at 19:04
  • I don't have any application in mind yet but I just feel like every recv call should have some sort of timeout when it is used in real scenarios right? – Curious Dec 30 '15 at 20:21
  • @Curious, there are many application which do not deal with any timeouts, and are just waiting for data or connection break. – SergeyA Dec 30 '15 at 20:42
  • How about a regular HTTP server? A recv() call in such a server should be with such a timeout correct? – Curious Dec 30 '15 at 21:10
  • @Curious, yes, HTTP servers (like many other servers) are the kind of applications which will close connection which doesn't seem to be alive anymore. – SergeyA Dec 30 '15 at 21:15
  • @Curious we have a tool assessing number of lost packages through a very noisy channel; timeouts just mark a package as lost for overall loss statistics, to mark connection as dead the timeout is significantly increased – ikudyk Oct 24 '22 at 12:42
1

select() and poll() just tell you which file descriptors are ready to read from. Once you know which file descriptors are ready you can still call recv() on them so you will get the same return values/error checking either way.

You really only need to use select() or poll() if you have multiple sockets/file descriptors to read from. If all you need is a timeout on a single socket then you can use setsockopt() with the SO_RCVTIMEO option to allow a recv() call to time out. See this answer.

Community
  • 1
  • 1
samt1903
  • 169
  • 1
  • 2
  • 11
  • poll has a benefit over SO_RCVTIMEO in that timeout is site configurable. However, this answer is a good one. – SergeyA Dec 30 '15 at 14:35
0

Answer to question beginning by "Is is a good idea to ALWAYS" are often "no." Here, the answer depends on the way you poll(), so no it's no always a good idea.

If you poll() in a separate thread whose goal is only to wait for data, a timeout won't do anything.

YSC
  • 38,212
  • 9
  • 96
  • 149
  • Assuming I poll in the same thread right before I call recv() or send(). And the call to poll() is statically well formatted, i.e. The parameters dont change dynamically besides how they do based on the invocation of the wrapped recv() or send()/ – Curious Dec 30 '15 at 14:32
-1

I you use the sockets in a syncron aproach, then you have to use timeouts. But a better but harder way would be to use them asyncron. So, running in their own thread, they can block and will use least resoures...

Dieter Meemken
  • 1,937
  • 2
  • 17
  • 22
  • Generally bad answer. In many cases there is absolultely no need to perform socket operation in separate thread. – SergeyA Dec 30 '15 at 14:32