D
D
Danil Tunev2019-12-17 08:34:04
linux
Danil Tunev, 2019-12-17 08:34:04

What could be the problem with Linux server?

I'm testing an http server written using functions from the header files sys/socket, sys/epoll and related ones. In general, the construction is designed as follows: the listening socket: s=socket(PF_INET,SOCK_STREAM,IPPROTO_TCP), is added to the epoll set with the EPOLLIN|EPOLLET mask. When epoll_wait returns an event on this socket, an accept() call returns a connection handle, then this handle is also added to the epoll set with the mask EPOLLIN|EPOLLOUT|EPOLLET (non-blocking sockets). Next, epoll_wait is expected to return, with events, if even[i].data.fd is equal to the listening socket, then (accept()) register a new connection descriptor, if even[i].data.fd is equal to the created connection descriptors, look at what even[i is equal to ].events if 1-read, 4-write, 5-read/write, if the value is greater than 5-(failure) close the connection and remove it from the epoll set. Reading and writing work like this: event 1: the internal switch (VI) is set to read (0) until it receives all the data VI = 1, naturally stop reading when returning -1 (errno is not checked), event 4: if VI == 1 we write until we send everything, after that VP=0, event 5: VP==0, read and write. (all reads and writes stop with a return of -1, the VI switches only after all data has been received/sent). In short, everything seems to be fine. When the server starts, 40-400 requests (in several tcp connections) are processed and sent as needed, then I notice that not all requests sent by the http client are received by the server, and accordingly the client does not receive a response, this continues in 20-30 requests, then the server "goes out" and after each tcp connection, it reads and writes a little and the next event is already >5, Accordingly, the connection is closed without missing a single response (as if the closure is initiated by the client). What is the problem? For a long time I can’t find a solution, I studied the nginx sources and noticed a lot of setsockopts (38 pieces) both on the listening socket and on the connection descriptors, but I think that the problem may not be in this, the inconsistency of the processed requests is somehow suspicious, sometimes it can handle 300-400 and sometimes it can handle 40 with an interference fit. Have you experienced something similar that could go wrong? I don't want to think, but maybe the problem is in the kernel? I have LINUX 4.9.0-8-686-pae. Give food for thought! ) and on the listening socket and on the connection descriptors, but something seems to be that the problem may not be in this, the inconsistency of the processed requests is somehow suspicious, sometimes it can process 300-400 and sometimes it copes with 40 with an interference fit. Have you experienced something similar that could go wrong? I don't want to think, but maybe the problem is in the kernel? I have LINUX 4.9.0-8-686-pae. Give food for thought! ) and on the listening socket and on the connection descriptors, but something seems to be that the problem may not be in this, the inconsistency of the processed requests is somehow suspicious, sometimes it can process 300-400 and sometimes it copes with 40 with an interference fit. Have you experienced something similar that could go wrong? I don't want to think, but maybe the problem is in the kernel? I have LINUX 4.9.0-8-686-pae. Give food for thought!

Answer the question

In order to leave comments, you need to log in

1 answer(s)
C
CityCat4, 2019-12-17
@lada-guy

Dear, your question is unreadable from the word at all. Break it up into paragraphs, decorate pieces of code with tags - maybe then someone will think. Nobody will overcome the stream of consciousness.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question