Thread: C / Unix: client program with listeninig socket

sorry for the dupe but the other thread (Server and client in the same program) was locked. anyway it's not exactly the same situation tho.


C / Unix
i have a client program which connects to a server via socket. works all nice and cozy.
now i want that program to also listen on a specific port for incoming connections. so i went ahead and created a second socket for that and it worked as expected. the problem however is the independent processing of what happens on each socket. i wanna do some stuff on the listening socket but totally different stuff on the client socket but i can only run one loop at a time which doesn't work right then obviously
i did search quite a lot but everything i found was always about separate client and server approaches but never combined in one single program.

so any help is most welcome


been lurking here for a while btw and enjoyed some nice posts every so often ^^

Originally Posted by YocR

the problem however is the independent processing of what happens on each socket. i wanna do some stuff on the listening socket but totally different stuff on the client socket

There are two common approaches:

1. POSIX threads (POSIX threads at Wikipedia, tutorial at LLNL)
   This allows you to run two or more loops simultaneously. The downside is that while the memory is shared, you'll need to use locking (or atomic builtins provided by the C compiler as an extension) to share state between the two threads, and you also must be wary of thread-safety (especially if using other libraries).
2. Non-blocking I/O, and merging the two (or more) loops into a single one

Which of these to select, and how to implement it, is absolutely dependent on what the loops are trying to accomplish. Details, especially how the two tasks interact and how data flows between the two, are of the utmost importance in deciding or advising on the approach.

If you want to tell us the exact problem you are trying to solve -- not how you have decided or intend to solve it, as that is irrelevant --, we should be able to help you with more details. (To be honest, your description of the problem is vague enough to be irritating.)

much thanks for the reply.
unfortunately i can't go into great detail about the program itself however i'll try to describe it more precisely.

the basic program was a client connecting to a server, reading what the server sent and reacting accordingly. that worked fine. there's a loop with recv() following a function for all further processing in case some data came through from the server.
now the new thing to add is a listener on a specific port. there some data should be recived and processed further. it is however only required to read from that.
from what i've seen so far select() looks suitable. adding my two sockets plus a third one for the client connecting to my listerner to the fd_set and reacting depending on which socket delivered the data.

Originally Posted by YocR

program was a client connecting to a server, [..] new thing to add is a listener on a specific port [read-only]

That is actually a pretty common situation.

Using non-blocking I/O, you can use select() (which was standardized in POSIX.1-2001, but is available on many other systems, due to it originating in old BSD4.2), or poll() (POSIX.1-2001, probably better suited interface, provides same or similar functionality). (Linux also provides epoll(), but I wouldn't recommend it for this particular case.)

The man 2 select_tut is an introduction to this kind of I/O multiplexing, and includes an example program that forwards TCP ports.

One very efficient "trick" is to use separate buffers for each data source and target (connected server, peer, or client), and only dispatch/process the buffer when you find that the buffer contains a complete request. More complex servers, like HTTP servers, split this into multiple steps so that important decisions can be made as soon as the data is there, but otherwise apply the same logic.

In my personal opinion, using a single thread to receive the data, and another thread to consume/process/dispatch complete messages, yields quite straightforward and efficient code. Instead of a single separate processing thread, usually a pool of threads is used; each thread just grabs (or waits for) the next available buffer to act on. The number of threads in that pool is easy to manage dynamically -- just have each thread check a counter when idle, and if there are too many idle threads, exit. This lets you (or your administrator users) configure the optimum number of threads for the task, regardless of the number of concurrent connections.

thanks again and indeed select() pretty much worked as i hoped for. what you added further is even a bit too advanced for what i need but is neat of course and i'll keep it in mind