linux-kernel - Re: epoll'ing tcp sockets for reading

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.0912190953160.4482@makko.or.mcafeemobile.com>
Date:	Sat, 19 Dec 2009 10:07:05 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Nikolai ZHUBR <zhubr@...l.ru>
cc:	linux-kernel@...r.kernel.org
Subject: Re: epoll'ing tcp sockets for reading

On Sat, 19 Dec 2009, Nikolai ZHUBR wrote:

> Hello people, I have a question about epoll'ing tcp sockets.
> 
> Is it possible (with epoll or some other good method) to get userspace
> notified not only of the fact that some data has become available
> for the socket, but also of the respective _size_ available for
> reading connected with this exact event?
> 
> Yes, read'ing until EAGAIN or using FIONREAD would provide this
> sort of information, but there is a problem. In case of subsequent
> continuous data arrival, an application could get stuck reading
> data for one socket infinitely (after epoll return, just before
> the next epoll), unless it implements some kind of artifical safety
> measures.

It is up to your application to handle data arrival correctly, according 
to the latency/throughput constraints of your software.
The "read until EAGAIN" that is cited inside the epoll man pages, does not 
mean that you have to exhaust the data in one single event processing loop.
After you have read and processed "enough data" (where enough depends on 
the nature and constraints of your software), you can just drop that fd 
into an "hot list" and pick the timeout for your next epoll_wait() 
depending on the fact that such list is empty or not (you'd pick zero if 
not empty). Proper handling of new and hot events will ensure that no 
connections will be starving for service.

- Davide

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/