0

I remake two detached threads to poll() cycle in server: for receiving and sending data. All work fine, until setting client's sending frequency to 16 ms (< ~200 ms). In this state one thread always wins the race and answers to only one client with ~1 us ping. What I need to do to send and receive data in poll() with two (or one) UDP sockets?

Part of server's code:

struct pollfd pollStruct[2];
// int timeout_sec = 1;

pollStruct[0].fd = getReceiver()->getSocketDesc();
pollStruct[0].events = POLLIN;
pollStruct[0].revents = 0;
pollStruct[1].fd = getDispatcher()->getSocketDesc();
pollStruct[1].events = POLLOUT;
pollStruct[1].revents = 0;

while(true) {
    if (poll(pollStruct, 2, 0 /* (-1 / timeout) */) > 0) {
        if (pollStruct[0].revents & POLLIN) {
            recvfrom(getReceiver()->getSocketDesc(), buffer, getBufferLength(), 0, (struct sockaddr *) &currentClient, getReceiver()->getLength());
            // add message to client's own thread-safe buffer
        }

        if (pollStruct[1].revents & POLLOUT) {
            // get message from thread-safe general buffer after processing
            // dequeue one
            if (!getBuffer().isEmpty()) {
                auto message = getBuffer().dequeue();
                if (message != nullptr) {
                    sendto(getDispatcher()->getSocketDesc(), "hi", 2, 0, message->_addr, *getDispatcher()->getLength());
                }
            }
        }

    }
}
  • Can you explain a bit more about the "race" you are concerned about ? Are you saying that the code you have is running in 2 threads and only one of them ever returns from poll() ? Are they polling the same socket, or have you created 2 different sockets ? – nos Aug 23 '18 at 13:09
  • @nos, receive and send in one thread now, post messages to different threads for get results in general queue after processing it in future. Race: all clients stack and waiting, except one of them. This one client have incorrect ping 1us. – AlsApps Aug 23 '18 at 13:13
  • Note that the error/problem description is exactly the same as it was for the previous (now deleted) question which used multiple threads rather than `poll`. That suggests -- to me at least -- that the real problem might lie elsewhere. – G.M. Aug 23 '18 at 13:18
  • 1
    @AlsApps So the error is likely in your queue processing rather than this code ? Can you atleast add some debugging *right* after your recvfrom() call to see which client addresses you are receiving data from ? – nos Aug 23 '18 at 13:19
  • @nos, for example, I can start two clients and it seems OK, all packets processed, but if I add another client / make another try for run a couple of clients - all (except one random client) will stack and recvfrom only from this guy with incorrect counted ping like 1 us. (I use ThreadSafe queues, consumer-producer pattern to interract with threads, like there: https://stackoverflow.com/questions/15278343/c11-thread-safe-queue and all is OK if I want to send() right after recv()). BUT I want to separate processing to threads, not in one thread. – AlsApps Aug 23 '18 at 13:31
  • @AlsApps That is fine, but if you need to fix your issue, you need to start debugging and find out where the issue is. You can't just guess from inferring results at your client side. Did you add the code right after `recvfrom()` where you print out the address of the client ? When you have done that, you must investigate the output and see if you are receiving the data from your client. When you have done that you have enough evidence to know whether the data was received or not, and you can move on to the next part to find out if there's an issue in the thread queuing or sending part. – nos Aug 23 '18 at 13:39
  • @nos, yes, after recvfrom() I can see that (if wait a bit) only one address sending packets (my client is one-threaded, they send info and then waiting for answer). So they all will stack for waiting answer from server (and not reply). Thanks I will continue finding mistake, but I asking this question after a long-timed debugging. – AlsApps Aug 23 '18 at 13:48
  • So if your server has received the packets, but not replied, then you can eliminate the poll() + recvfrom() call, and you should track the packets to see where they end up in your queue in the server code and find why you never get them back from your `getBuffer()` call to send the reply. – nos Aug 23 '18 at 13:57

0 Answers0