0

i have this question, that i think is more theoretical than pratical.

I have a server, that receives connections from clients, with select() function.

Server has a pattern master-slave where slave are threads that take file descriptor from master and manage request from specific client.

(Every request from client start with a connection request)

I think that select() function must understand that same client asks some requests, because if same client asks two requests and select function can't understand that is same client, select create two file descriptor for same client with accept() and after two different threads manage a different request from same client and i think this can create a lot of concurrency problems because different threads write in different file descriptors but the real channel with client is the same.

So, i would like to know, how can select() recognise a client after the first request?

soissy
  • 86
  • 1
  • 10
  • 2
    It can't - not without the client sending some kind of identification. But that probably shouldn't matter as your clients should re-use the same connection if their requests should be processed in sequence. – Chris Turner Sep 11 '17 at 08:39
  • 1
    Not related to your question but... Using both `select` and one thread per connection is overkill. Either use a single-threaded server with `select` or use one thread per connection without `select`. `select` is only needed when a single thread needs to manage multiple connections. – Klas Lindbäck Sep 11 '17 at 08:46
  • I have clients, so server has to manage many requests, in fact i use select() to do not use multithreading for any connection and after to know what client(file descriptor) ask request, the request is managed by a thread(there are many thread), but only the request is managed by thread(not the connection). – soissy Sep 11 '17 at 09:18
  • 1
    What kind of concurrency problems you suspect when you recv and reply to same client application on two diffrent sockets, two requests being handled on two sockets should not interfere with one another – Pras Sep 11 '17 at 09:35
  • If you have a new connection from any client, "but the real channel with client is the same" is not true. The connection is the channel. If a client program sends 2 connection request, it must be able to handle answers from both connections. Same for the server side. – Gerhardh Sep 11 '17 at 13:04
  • @Pras Server is master-slave with some threads (slaves), every thread manage a client request, but if the same client asks two requests but the server doesn't know that is the same client because reads only file descriptor, and server gives to any client a different file descriptor for any request, the concurrency is here, where, for example, two different threads manage two different requests from same client, i think when threads write on socket they are writing to same channel not server size but client size yes. – soissy Sep 12 '17 at 15:48
  • @Gerhardh "If a client.. ...both connections", yes i agree with this but in my case client asks only the first time a possibility to connected and other times requests. The requests are send to the same channel because client has only a socket opened with server. The problem is that any client before asks some request, ask prevently to connected with server, and so server (if doesn't recognise client, **that is my problem**) every time with accept() give a different file descriptor and so threads take request and manage it, but write in reality to the same client. – soissy Sep 12 '17 at 15:56
  • I still did not understand whats the problem when you have 2 threads handling same client over 2 diffrent sockets, both requests getting served concurrently over two diffrent threads – Pras Sep 13 '17 at 05:10

0 Answers0