0

To begin with, I know there are ways to handle multiple client requests by forking or threading. But I cannot understand why there cannot be multiple acceptance by the server without forking or threading. accept() call can simply accept all process wish to connect to it. Why cannot the the call(accept()) go on unless a client cut its connection??

server does socket(), listen() and bind() with blocking(default) way

client does likewise by default socket() and connect()

What I think is accept's returned value will be for the recent child. But in reality it blocks until the prior client(s) cut its connection.

concurrencyboy
  • 351
  • 1
  • 11
  • 1
    Not really sure exactly what you mean by: *"But in reality it blocks until the prior client(s) cut its connection."* In blocking mode, `accept` blocks until a connection is present and then returns the file descriptor. You can put `accept` in non-blocking mode too, if you'd like: *"If the socket is marked nonblocking and no pending connections are present on the queue, accept() fails with the error EAGAIN or EWOULDBLOCK."* – MFisherKDX May 14 '19 at 16:54
  • @MFisherKDX thanks for your answer. What happens two client at the same wants to connect to the single process server?? – concurrencyboy May 14 '19 at 16:58
  • You have to somehow manage the client IO. You could use `select` to determine when IO is available and then serve the clients as appropriate. – MFisherKDX May 14 '19 at 17:01
  • Possible duplicate of [Can a server handle multiple sockets in a single thread?](https://stackoverflow.com/questions/18840440/can-a-server-handle-multiple-sockets-in-a-single-thread) – Daniel Pryden May 14 '19 at 17:08
  • @MFisherKDX **I wonder whether there is file-descriptor which is returned by accept() overwriting? If not, how? There must be. That's the point I don't understand** – concurrencyboy May 14 '19 at 18:25
  • @concurrencyboy "*What happens two client at the same wants to connect to the single process server??*" - then `accept()` returns the first available client from the queue, and the other client stays in the queue until `accept()` is called again. A responsive server should be calling `accept()` frequently, processing each accepted client in a fork or thread as needed, or else putting everything into non-blocking mode and then using `select()` or `(e)poll()` to decide when to accept a new client and when to read/write from/to a client. – Remy Lebeau May 15 '19 at 20:37

1 Answers1

0

I wonder whether there is file-descriptor which is returned by accept() overwriting? If not, how?

There is no overwriting; accept() creates a new connected socket, and returns a new file descriptor referring to that socket - a new, distinct one each time. Of course, a server which manages all client connections without creating other threads must store all those file descriptors, e. g. in an array.

Armali
  • 18,255
  • 14
  • 57
  • 171