Re: send(2) does not block, send(2) man page wrong?

From: Luigi Rizzo (rizzo_at_icir.org)
Date: 01/26/04

  • Next message: Steve Watt: "Re: send(2) does not block, send(2) man page wrong?" 
    Date: Mon, 26 Jan 2004 11:16:22 -0800
To: Julian Elischer <julian@elischer.org>

    On Mon, Jan 26, 2004 at 10:53:54AM -0800, Julian Elischer wrote:
    ...
    > On Mon, 26 Jan 2004, Stuart Pook wrote:
    >
    > > > On 23 Jan 2004, Don Lewis wrote:
    > > > > the send does not give an error: the packet is just thrown away.
    > > >
    > > > Which is the same result as you would get if the bottleneck is just one
    > > > network hop away instead of at the local NIC.
    > >
    > > But it isn't. I'm broadcasting onto the local network. With Linux and
    > > Solaris (which implement what FreeBSD send(2) says), it is so easy: I just
    > > send(2) away, and because the send blocks when the kernel buffer space is

    I'd be really curious to know how Linux/Solaris actually implement
    this blocking send and if they really block or use some kind
    of timeout/retry loop in the kernel.

    To implement a blocking send() on UDP sockets, you need a different
    driver model from the one we have, one where sockets and other data
    sources trying to access a full interface queue should be queued
    into some kind of list hanging off the interface, so that when the
    interface is ready again you can wake up the pending clients in
    turn and process their requests.

    This would cause the output queue to become effectively
    unbounded (basically, it is like reserving at least one slot
    per socket -- more if you want to deal with fragments),
    and even if the slot can be allocated as part of
    the socket, the delay would become unbounded as well.
    Secondly, if the interface for some reason goes "temporarily"
    down (e.g. no-carrier or the like) the process would suddenly
    block unless you mark the socket as non blocking.

            cheers
            luigi
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

  • Next message: Steve Watt: "Re: send(2) does not block, send(2) man page wrong?"

    Relevant Pages

    • Re: recv blocks although socket is ready
      ... of the members of the interface in my network layer have blocking ... Only one has non-blocking semantics. ... call any socket operation and rely on the socket to block. ... Now I have to implement blocking myself in all other ...
      (microsoft.public.win32.programmer.networks)
    • Re: [PATCH} Network interface for IPMI
      ... af_ipmi - A network socket interface to IPMI. ... -Note that the KCS-only interface ahs been removed. ... struct sockaddr_ipmi saddr; ...
      (Linux-Kernel)
    • Re: Async socket & active connections
      ... The "blocking = true" in the disconnect phase seems to solve the ... Socket and TcpClient, ... blocking connection somewhere down the line. ... 300K connections, enough to start worrying... ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: ntpd and network sockets
      ... it is unfortunate that both interface ... small" and then blythly ignore the socket entirely. ... that the stacks "socket buffer overflow" stat will increase I ... overflow in the ntpd itself. ...
      (comp.protocols.time.ntp)
    • Re: [RFC] 0/11 fanotify: fscking all notifiction and file access system (intended for antivirus scan
      ... deals with races and exclusion. ... notification file open have very minimal performance hit. ... Ok that is foul as an interface, ... can't use the socket based notification model - that gives you a much ...
      (Linux-Kernel)