One Task to Rule Them All (TCP accept)

Discussion to talk about software related topics only.
Post Reply
zealott
Posts: 40
Joined: Thu Oct 30, 2008 1:15 am

One Task to Rule Them All (TCP accept)

Post by zealott »

Ok, so with serial ports I can have one select that works on all ports by using FD_SET.
This obviously work the same for all filedescriptors, however is it possible to combine the listen/accept in the same instead of having those in a separate task? (let say I want to have 10 TCP server ports available, I'd hate to use 10 tasks for that).

Any hints?
sulliwk06
Posts: 118
Joined: Tue Sep 17, 2013 7:14 am

Re: One Task to Rule Them All (TCP accept)

Post by sulliwk06 »

The listen call returns a socket, so you should be able to add that socket into your fd set for the select call, and then accept new connections inside there.
User avatar
pbreed
Posts: 1081
Joined: Thu Apr 24, 2008 3:58 pm

Re: One Task to Rule Them All (TCP accept)

Post by pbreed »

Not sure if your in 3.X or 2.9.X land...

In 2.9.X:
nburn\examples\StandardStack\TCP\TcpMultiSocket

In 3.X
\nburn\examples\TCP\TcpMultiSocketServer

Both basically the same example.
Look for the comments with the word listen .....
zealott
Posts: 40
Joined: Thu Oct 30, 2008 1:15 am

Re: One Task to Rule Them All (TCP accept)

Post by zealott »

Thanks, for some weird reason I thought listen() would block and not go further until a connection has been made...
User avatar
pbreed
Posts: 1081
Joined: Thu Apr 24, 2008 3:58 pm

Re: One Task to Rule Them All (TCP accept)

Post by pbreed »

Yeah listen just opens the port for listening,
accept is the one that actuall blocks if ther eis no pending connection..
And select wakes up when you wait for data on a listening socket...

Its possible to wake up for a connection and have accept fail, if the other side has closed the socket before you accepted it..
Post Reply