lkml.org 
[lkml]   [2008]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectHonoring SO_RCVLOWAT in proto_ops.poll methods
Hello lkml,

I have a need for select/poll/epoll_wait to block on sockets which have
unread data sitting in the receive buffer with a quantity less than
specified via setsockopt() w/SO_RCVLOWAT, not less than one like the
current implementation.

Upon looking at the code in net/ipv4/tcp.c it doesn't look like this
would be difficult to support. Something along the lines of changing
the function tcp_poll() of version 2.6.26.5 from doing this:

394 if ((tp->rcv_nxt != tp->copied_seq) &&
395 (tp->urg_seq != tp->copied_seq ||
396 tp->rcv_nxt != tp->copied_seq + 1 ||
397 sock_flag(sk, SOCK_URGINLINE) || !tp->urg_data))
398 mask |= POLLIN | POLLRDNORM;

to this:

394 if ((tp->rcv_nxt != tp->copied_seq) &&
395 (tp->urg_seq != tp->copied_seq ||
396 tp->rcv_nxt > tp->copied_seq + sk->sk_rcvlowat ||
397 sock_flag(sk, SOCK_URGINLINE) || !tp->urg_data))
398 mask |= POLLIN | POLLRDNORM;


I imagine it's similarly simple for the other socket types. Am I
missing something? Is there a technical reason why Linux only blocks in
read/recv but not the poll with respect to the SO_RCVLOWAT setting?


For those interested the application is basically doing:

1: Wait for input on active sockets with epoll_wait()
2: Recv() data off the eventful sockets with MSG_PEEK flag, parse contents
looking for specific keyword and value from buffer.
3: If buffer is too short call setsockopt() with SO_RCVLOWAT parameter set
greater than what recv() with MSG_PEEK returned.

Repeat @ 1 until finding what's needed or shutdown/error/timeout.

Once the value is parsed it's used as an address to locate (with a db
lookup) a path which would be a unix domain socket for passing the
socket descriptor through. The unrelated process at the other end needs
to accept the descriptor and use it as if no other program mucked with it
hence the MSG_PEEK magic.

As-is I must basically tie up threads in blocked recv() calls after
increasing SO_RCVLOWAT if the first recv() peek falls short. This
solution obviously doesn't scale well.

Thanks,
Vito Caputo


\
 
 \ /
  Last update: 2008-09-20 23:51    [W:0.062 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site