0

My question about epoll based non blocking event driven network IO is this - how does the client connection to the epoll service provider remain open? Why doesn't the connection on the client side die when there isn't a permanent receiver on the server side?

How can the client connection remain open (Keep-Alive on a POST) when the server has processed the request and supposedly moved on.

skaffman
  • 398,947
  • 96
  • 818
  • 769
Pradeep
  • 148
  • 1
  • 9
  • Are you talking about [this epoll](http://www.kernel.org/doc/man-pages/online/pages/man4/epoll.4.html)? Because if you are, I don't understand your question at all. – Mat May 04 '12 at 21:01
  • A client can connect to a web server which is driven by epoll and in some cases the client connection can remain open for a long time. How can the client connection remain open (Keep-Alive on a POST) when the server has processed the request and supposedly moved on. – Pradeep May 04 '12 at 21:10

1 Answers1

1

Your assumption is wrong: there still is a permanent receiver on the server side.

Using epoll, select or plain blocking read/writes doesn't change anything on the networking side of things. There still is a persistent TCP session (in the case you state). The server process still has a file descriptor open on that connection.
epoll is "just" an API that allows the kernel to signal that there is stuff to do on that connection in an efficient, asynchronous manner.

Mat
  • 202,337
  • 40
  • 393
  • 406
  • Ah ... I see. So the burden of number of connections is not removed. The problem still remains as to how many such connection one can open to a machine. – Pradeep May 04 '12 at 21:24
  • You are correct, using epoll or not doesn't change the number of connections the server must maintain. – Mat May 04 '12 at 21:28