I need clarification on whether it is okay to set socket options on a listening socket
simultaneously when it is being used in an accept() call?
Following is the scenario:-
-- Task 1 - is executing in a loop - polling a listen socket, lets call it 'fd', (whose file descriptor is global) for an incoming connection request with select() and then executing accept(fd,...) when a connection request arrives.
-- Task 2 - is a task that receives config commands from console and manipulates internal structures in response to them. As part of a particular command, it sets an option on the same listen socket using setsockopt(fd,....)
The option must be set on the listen socket fd ONLY when intimated to do so via a console command.
Can someone please clarify if it is okay to perform setsockopt on a socket when the same is being used in a simultaneous accept() call in another task?
What you are working with in essence is a file descriptor, unless you are making a call to another protocol level. Since the socket has bind() already called on it you cannot change lower level protocol settings.
Just like with open files, some changes are okay, others not. I have no idea what you are trying to change, so try it, and see what error return you get, if any.
I am trying to set TCP_MD5SIG option. I am trying this on an application running on the Linux kernel 2.5.25 which has support for this option. When my application is configured via the console to set an MD5 password for a peer, it is set on the listen socket. This is as per the usage of this option on Linux.
But in another task, the same socket is polled continuously for incoming connection requests via select(), accept(). So, is it correct to do so?