|
Home > Archive > Unix Programming > July 2006 > What blocks a write to a socket pair?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
What blocks a write to a socket pair?
|
|
|
| I've set up a bunch of socketpairs and they're being used to
communicate between a collection of threads. These socketpairs are
generally non-blocking - I'd rather lose my message than block up a
thread. They are also currently set up as SOCK_STREAM, rather than
SOCK_DGRAM. Using getsockopt I find that the buffers are 65535 in size
as expected and I can't see how I could be filling that buffer - unless
the one buffer is shared between ALL socketpairs in a process. I'm
running (and have to stay on) Linux kernel 2.4.19 and glibc 2.1.2.
Now to some questions!
What will cause a socketpair to block (or report that it would have
blocked) a write?
Is it possible for the write to only write part of the data or will
this not ever happen in practice?
Would SOCK_DGRAM alleviate some of these issues given that I am
essentially using the socketpair as a message queue?
And no, I can't switch to the more traditional methods for a message
queue :-(
Many thanks,
Joe
| |
| davids@webmaster.com 2006-07-20, 7:51 am |
|
Joe wrote:
> What will cause a socketpair to block (or report that it would have
> blocked) a write?
You may get a block or a would block indication any time the operating
system cannot queue the data at that particular time. The expected case
would be if the send queue is full, however, memory pressure may cause
a write operation to block when you would not expect it to.
> Is it possible for the write to only write part of the data or will
> this not ever happen in practice?
Yes for a stream socket, no for a datagram socket.
> Would SOCK_DGRAM alleviate some of these issues given that I am
> essentially using the socketpair as a message queue?
Not likely, and it would add a whole host of new problems. You'd have
to deal with datagram loss and transmit pacing.
I would advise you to think a bit more about why you're having these
issues. There are a lot of silly little things you might be doing on
the read side that can give you problems on the write side. For
example, you may be holding a lock that makes it appear that the write
is blocking when actually you're blocking on the lock acquisition
before the write.
DS
| |
|
| Thanks for your help. I am confused by your comment about DGRAM packets
however - I thought they were reliable and ordered when talking over a
unix domain socketpair, as opposed to what happens when using them over
normal sockets?
davids@webmaster.com wrote:
> Joe wrote:
>
>
> You may get a block or a would block indication any time the operating
> system cannot queue the data at that particular time. The expected case
> would be if the send queue is full, however, memory pressure may cause
> a write operation to block when you would not expect it to.
>
>
> Yes for a stream socket, no for a datagram socket.
>
>
> Not likely, and it would add a whole host of new problems. You'd have
> to deal with datagram loss and transmit pacing.
>
> I would advise you to think a bit more about why you're having these
> issues. There are a lot of silly little things you might be doing on
> the read side that can give you problems on the write side. For
> example, you may be holding a lock that makes it appear that the write
> is blocking when actually you're blocking on the lock acquisition
> before the write.
>
> DS
| |
| Nils O. Selåsdal 2006-07-20, 1:23 pm |
| davids@webmaster.com wrote:
> Joe wrote:
>
>
> You may get a block or a would block indication any time the operating
> system cannot queue the data at that particular time. The expected case
> would be if the send queue is full, however, memory pressure may cause
> a write operation to block when you would not expect it to.
>
>
> Yes for a stream socket, no for a datagram socket.
Well, if you exceed the max datagram size, it might just chop off
those bytes.
>
> Not likely, and it would add a whole host of new problems. You'd have
> to deal with datagram loss and transmit pacing.
These are non-issues on local/unix sockets. They guarantee in
sequence delivery, and have "flow" control.
| |
| Frank Cusack 2006-07-20, 1:23 pm |
| On 20 Jul 2006 15:11:11 +0200 "Nils O. Selåsdal" <noselasd@asgaard.homelinux.org> wrote:
> davids@webmaster.com wrote:
>
> These are non-issues on local/unix sockets. They guarantee in
> sequence delivery, and have "flow" control.
Where (documentation) is in sequence delivery guaranteed?
thanks
-frank
| |
| Maxim Yegorushkin 2006-07-20, 7:24 pm |
|
Frank Cusack wrote:
> On 20 Jul 2006 15:11:11 +0200 "Nils O. Sel=E5sdal" <noselasd@asgaard.home=
linux.org> wrote:
>
> Where (documentation) is in sequence delivery guaranteed?
fc5: man unix(7)
Valid types are: SOCK_STREAM, for a stream-oriented
socket and
SOCK_DGRAM, for a datagram-oriented socket that preserves
message
boundaries (as on most Unix implementations, Unix domain
datagram sock-
ets are always reliable and don't reorder datagrams); and (since
kernel
2.6.4) SOCK_SEQPACKET, for a connection-oriented socket that
preserves
message boundaries and delivers messages in the order that
they were
sent.
| |
| davids@webmaster.com 2006-07-20, 7:24 pm |
|
Maxim Yegorushkin wrote:
> SOCK_DGRAM, for a datagram-oriented socket that preserves
> message
> boundaries (as on most Unix implementations, Unix domain
> datagram sock-
> ets are always reliable and don't reorder datagrams); and (since
> kernel
Note that this is "as on most Unix implementations". The standards
explicitly say that reliability is not guaranteed and, AFAIK, are
silent on whether reordering is possible.
DS
| |
| davids@webmaster.com 2006-07-20, 7:24 pm |
|
Joe wrote:
> Thanks for your help. I am confused by your comment about DGRAM packets
> however - I thought they were reliable and ordered when talking over a
> unix domain socketpair, as opposed to what happens when using them over
> normal sockets?
SuSv3's documentation on 'socketpair' says:
SOCK_DGRAM
Provides datagrams, which are connectionless-mode, unreliable messages
of fixed maximum length.
I can't find anything to the contrary.
DS
| |
| Barry Margolin 2006-07-21, 1:29 am |
| In article <1153428274.089190.265200@75g2000cwc.googlegroups.com>,
davids@webmaster.com wrote:
> Maxim Yegorushkin wrote:
>
>
> Note that this is "as on most Unix implementations". The standards
> explicitly say that reliability is not guaranteed and, AFAIK, are
> silent on whether reordering is possible.
So they're not de jure reliable, but they are de facto reliable, which
may be good enough for most situations.
Network datagram sockets are unreliable because there's no way for the
protocol to make up for the inherent unreliability of the network itself
(you need features of TCP to accomplish this). But Unix-domain sockets
are in control of the data from end-to-end, so there's no good reason
why anyone would implement them in an unreliable fashion. So they don't.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Maxim Yegorushkin 2006-07-21, 7:28 am |
|
davids@webmaster.com wrote:
> Maxim Yegorushkin wrote:
>
>
> Note that this is "as on most Unix implementations". The standards
> explicitly say that reliability is not guaranteed and, AFAIK, are
> silent on whether reordering is possible.
David, thank you for your illuminating answers in "select() says input
available, read() *sometimes* blocks" thread.
I may be wrong, but the only thing that seems to be able to make unix
local sockets unreliable is memory pressure you mentioned in another
thread. A programmer usually expects that once he allocated memory that
memory can not be gone until it's explicitly deallocated. This
expectation is often applied to unix sockets, i.e. it may be expected
that when data is written to a unix socket memory is allocated (or it
was preallocated) and data is copied there. IMO, it would be very
surprising in an unpleasant way if data written to a unix socket was
dropped by the kernel due to memory pressure. May be naive, but natural
expectation is that when memory is low a write() should fail, but
successfully written data should be delivered. Am I missing something?
| |
| davids@webmaster.com 2006-07-22, 1:22 am |
|
Maxim Yegorushkin wrote:
> I may be wrong, but the only thing that seems to be able to make unix
> local sockets unreliable is memory pressure you mentioned in another
> thread.
No. Linux can drop UDP packets for other reasons too. (For example, a
subsequent determination that the checksum was invalid.)
> A programmer usually expects that once he allocated memory that
> memory can not be gone until it's explicitly deallocated. This
> expectation is often applied to unix sockets, i.e. it may be expected
> that when data is written to a unix socket memory is allocated (or it
> was preallocated) and data is copied there. IMO, it would be very
> surprising in an unpleasant way if data written to a unix socket was
> dropped by the kernel due to memory pressure. May be naive, but natural
> expectation is that when memory is low a write() should fail, but
> successfully written data should be delivered. Am I missing something?
I don't disagree with you. The problem is, actual real-world code has
made these kinds of assumptions and broken when they weren't true. All
I'm trying to point out is that the idea that POSIX guarantees this is
a misconception, it does not do so.
The problem is not the things you can think of, it's the things you
can't think of. They may not even exist today, and code that relies
upon them not being there will in fact break as it has in the past.
DS
| |
| Frank Cusack 2006-07-22, 1:22 am |
| On 21 Jul 2006 18:17:10 -0700 davids@webmaster.com wrote:
> Maxim Yegorushkin wrote:
>
>
> No. Linux can drop UDP packets for other reasons too. (For example, a
> subsequent determination that the checksum was invalid.)
We're not talking about UDP packets here, we're talking about unix domain
sockets. Linux, apparently, guarantees in-order reliable delivery of
SOCK_DGRAM packets over a unix domain socket. Although, I wouldn't count
on it since the documentation and the implementation are written by folks
completely removed from each other ... with Linux they are not documenting
a specification they are documenting observed behavior (at a point in time).
As for the invalid checksum problem, I wonder if read() would actually
return (with an error), or if it's just the case that select() is
speculating. If the latter, this is invalid even given the lack of
guarantee by POSIX. Anyone care to look at the source?
-frank
| |
| davids@webmaster.com 2006-07-22, 1:22 am |
|
Frank Cusack wrote:
> We're not talking about UDP packets here, we're talking about unix domain
> sockets. Linux, apparently, guarantees in-order reliable delivery of
> SOCK_DGRAM packets over a unix domain socket.
I believe that is correct. It actually doesn't seem to state that it
guarantees they'll be received in order, but it would seem extremely
bizarre to guarantee they're reliable and not guarantee they're
received in order.
> Although, I wouldn't count
> on it since the documentation and the implementation are written by folks
> completely removed from each other ... with Linux they are not documenting
> a specification they are documenting observed behavior (at a point in time).
Right, that's the big problem here.
> As for the invalid checksum problem, I wonder if read() would actually
> return (with an error), or if it's just the case that select() is
> speculating. If the latter, this is invalid even given the lack of
> guarantee by POSIX. Anyone care to look at the source?
No, it's not invalid given the lack of guarantee by POSIX. POSIX does
not prevent an implementation from dropping a UDP datagram at any time.
As far as the application can tell, the behavior is the same as if the
implementation decided to drop a valid datagram after the 'select'
returned a read hit and before the 'read' was called. So it's allowed
under the 'as-if' rule.
DS
|
|
|
|
|