> and the parallel portions/comments in unix_dgram_recvmsg(),
> it looks like there's been a lot of uncertainty as to how
> file descriptor passing should be handled durning MSG_PEEK
> operations. To quote:
The specs basically don't answer the question. What is critical is that
the behaviour
Here's what I think is a better patch. Or maybe just simpler.
However, I'm still unsure what the effect of this patch on
file descriptor passing might be. Reading the prior code,
and the parallel portions/comments in unix_dgram_recvmsg(),
it looks like there's been a lot of uncertainty as to
Here's what I think is a better patch. Or maybe just simpler.
However, I'm still unsure what the effect of this patch on
file descriptor passing might be. Reading the prior code,
and the parallel portions/comments in unix_dgram_recvmsg(),
it looks like there's been a lot of uncertainty as to
and the parallel portions/comments in unix_dgram_recvmsg(),
it looks like there's been a lot of uncertainty as to how
file descriptor passing should be handled durning MSG_PEEK
operations. To quote:
The specs basically don't answer the question. What is critical is that
the behaviour does
On Thu, 10 Jan 2008, Herbert Xu wrote:
> Having said that, I do agree that having TCP and AF_UNIX behave
> in the same way is a plus. However, if you really want this to
> happen it would help if you had attached a patch :)
The following patch appears to fix the problem. However, I would
On Thu, 10 Jan 2008, Herbert Xu wrote:
> The POSIX text for MSG_WAITALL actually says that when used in
> conjunction with MSG_PEEK it may not return the full data.
That's fine. The problem is that the peek operation returns less
data than requested even when sufficient data is available on the
Brent Casavant <[EMAIL PROTECTED]> wrote:
>
>> Did you try MSG_WAITALL flag? See "man 2 recv".
>> A TCP socket handles data in bytes.
>> You cannot complain if the amount received by recv() is smaller than expected
>> unless you use MSG_WAITALL flag.
>
> Yes. It made no difference, as noted in
On Wed, 9 Jan 2008, Tetsuo Handa wrote:
> Did you try MSG_WAITALL flag? See "man 2 recv".
> A TCP socket handles data in bytes.
> You cannot complain if the amount received by recv() is smaller than expected
> unless you use MSG_WAITALL flag.
Yes. It made no difference, as noted in the comments
Hello.
Brent Casavant wrote:
> However, the program would occasionally get into a situation where
> a call to recv(sockfd, , len, MSG_PEEK) returns some number
> of bytes less than the requested length, and persists in this state
> (i.e. retrying the call continues to return the same amount of
Hello.
Brent Casavant wrote:
However, the program would occasionally get into a situation where
a call to recv(sockfd, buf, len, MSG_PEEK) returns some number
of bytes less than the requested length, and persists in this state
(i.e. retrying the call continues to return the same amount of
On Wed, 9 Jan 2008, Tetsuo Handa wrote:
Did you try MSG_WAITALL flag? See man 2 recv.
A TCP socket handles data in bytes.
You cannot complain if the amount received by recv() is smaller than expected
unless you use MSG_WAITALL flag.
Yes. It made no difference, as noted in the comments in the
Brent Casavant [EMAIL PROTECTED] wrote:
Did you try MSG_WAITALL flag? See man 2 recv.
A TCP socket handles data in bytes.
You cannot complain if the amount received by recv() is smaller than expected
unless you use MSG_WAITALL flag.
Yes. It made no difference, as noted in the comments in
On Thu, 10 Jan 2008, Herbert Xu wrote:
The POSIX text for MSG_WAITALL actually says that when used in
conjunction with MSG_PEEK it may not return the full data.
That's fine. The problem is that the peek operation returns less
data than requested even when sufficient data is available on the
On Thu, 10 Jan 2008, Herbert Xu wrote:
Having said that, I do agree that having TCP and AF_UNIX behave
in the same way is a plus. However, if you really want this to
happen it would help if you had attached a patch :)
The following patch appears to fix the problem. However, I would
really
On Tue, 8 Jan 2008, Tom Spink wrote:
> Ach. I *am* missing something... and what I'm missing is my
> understanding of the sendmsg and recvmsg calls.
No problem. We all have those days. :)
Brent
--
Brent Casavant All music is folk music. I ain't
[EMAIL PROTECTED]
On 08/01/2008, Tom Spink <[EMAIL PROTECTED]> wrote:
> On 08/01/2008, Brent Casavant <[EMAIL PROTECTED]> wrote:
> > On Tue, 8 Jan 2008, Tom Spink wrote:
> >
> > > Where in the code is the message length being sent across the socket?
> >
> > In do_producer(), there are the following lines in the
On 08/01/2008, Brent Casavant <[EMAIL PROTECTED]> wrote:
> On Tue, 8 Jan 2008, Tom Spink wrote:
>
> > Where in the code is the message length being sent across the socket?
>
> In do_producer(), there are the following lines in the main loop:
>
> /* Send random lengths of data */
>
On Tue, 8 Jan 2008, Rick Jones wrote:
> Potential bugs notwithstanding, given that this is a STREAM socket, and as
> such shouldn't (I hope, or I'm eating toes for dinner again) have side effects
> like tossing the rest of a datagram, why are you using MSG_PEEK? Why not
> simply read the N bytes
On Tue, 8 Jan 2008, Tom Spink wrote:
> Where in the code is the message length being sent across the socket?
In do_producer(), there are the following lines in the main loop:
/* Send random lengths of data */
messages[i].length = (rand() % MAXLEN) + sizeof(size_t);
On 08/01/2008, Rick Jones <[EMAIL PROTECTED]> wrote:
> Potential bugs notwithstanding, given that this is a STREAM socket, and
> as such shouldn't (I hope, or I'm eating toes for dinner again) have
> side effects like tossing the rest of a datagram, why are you using
> MSG_PEEK? Why not simply
Potential bugs notwithstanding, given that this is a STREAM socket, and
as such shouldn't (I hope, or I'm eating toes for dinner again) have
side effects like tossing the rest of a datagram, why are you using
MSG_PEEK? Why not simply read the N bytes of the message that will have
the message
Hello,
I was coding an application which passes variable-length messages
over an AF_UNIX SOCK_STREAM socket. As such I would pass a message
length embedded as the first element in the message, use recv(...,MSG_PEEK)
to determine the message length, and perform the necessary allocation
on the
On 08/01/2008, Rick Jones [EMAIL PROTECTED] wrote:
Potential bugs notwithstanding, given that this is a STREAM socket, and
as such shouldn't (I hope, or I'm eating toes for dinner again) have
side effects like tossing the rest of a datagram, why are you using
MSG_PEEK? Why not simply read the
Hello,
I was coding an application which passes variable-length messages
over an AF_UNIX SOCK_STREAM socket. As such I would pass a message
length embedded as the first element in the message, use recv(...,MSG_PEEK)
to determine the message length, and perform the necessary allocation
on the
On Tue, 8 Jan 2008, Rick Jones wrote:
Potential bugs notwithstanding, given that this is a STREAM socket, and as
such shouldn't (I hope, or I'm eating toes for dinner again) have side effects
like tossing the rest of a datagram, why are you using MSG_PEEK? Why not
simply read the N bytes of
On Tue, 8 Jan 2008, Tom Spink wrote:
Where in the code is the message length being sent across the socket?
In do_producer(), there are the following lines in the main loop:
/* Send random lengths of data */
messages[i].length = (rand() % MAXLEN) + sizeof(size_t);
On 08/01/2008, Brent Casavant [EMAIL PROTECTED] wrote:
On Tue, 8 Jan 2008, Tom Spink wrote:
Where in the code is the message length being sent across the socket?
In do_producer(), there are the following lines in the main loop:
/* Send random lengths of data */
On 08/01/2008, Tom Spink [EMAIL PROTECTED] wrote:
On 08/01/2008, Brent Casavant [EMAIL PROTECTED] wrote:
On Tue, 8 Jan 2008, Tom Spink wrote:
Where in the code is the message length being sent across the socket?
In do_producer(), there are the following lines in the main loop:
On Tue, 8 Jan 2008, Tom Spink wrote:
Ach. I *am* missing something... and what I'm missing is my
understanding of the sendmsg and recvmsg calls.
No problem. We all have those days. :)
Brent
--
Brent Casavant All music is folk music. I ain't
[EMAIL PROTECTED]
29 matches
Mail list logo
