So, why didn't you immediately type "man listen" at the shell prompt on your operating system of choice?
When I do that on a similar system, I immediately noticed:
If a connection request arrives when the queue is full, the client may receive an error with an indication of ECONNREFUSED or, if the underlying protocol supports retransmission, the request may be ignored so that a later reattempt at connection succeeds.
Seems a quite stupid feature to allow one to reduce how much one wants to queue up connections in a way that is designed to cause the client side to just queue up connections in a different way. *shrug*
Given that, you'll probably want two streams of execution where one stream does work and the other stream actively rejects connections. There are lots of choices when it comes to having multiple streams of execution in Perl, but each of the choices usually have drawbacks that can become significant. But, for this simple case, you can probably use most of them without problems.
If you can't guarantee one stream has "priority" so that the other stream only receives connections when the first is busy, then you'll probably want a non-blocking semaphore / lock / critical section so each stream can know when it should just reject.
For this case, I'd probably just use threads.pm with a shared variable (despite usually finding myself in situations where Perl "threads" aren't the best solution). Note that you'll need to explicitly lock the shared variable around your 'test and set' code. See also: threads::shared.
- tye
In reply to Re: TCP server: How to reject connections when busy? (some FM TR)
by tye
in thread TCP server: How to reject connections when busy?
by squirrel
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |