> On Wed, 28 Jun 2000 10:15:08 -0700 (PDT),
> Tim Hartrick <[EMAIL PROTECTED]> said:
>> It's true that flow IDs are source oriented, but if sin6_scope_id is
>> ignored in (e.g.) connect(), how can we call connect() without binding
>> beforehand and with specifying the flow ID?
> I assum
Jinmei,
>
> It's true that flow IDs are source oriented, but if sin6_scope_id is
> ignored in (e.g.) connect(), how can we call connect() without binding
> beforehand and with specifying the flow ID?
>
I assume you intended to say sin6_flowinfo above.
The answer is, you couldn't. If you wa
> On Wed, 21 Jun 2000 17:13:48 -0700 (PDT),
> Tim Hartrick <[EMAIL PROTECTED]> said:
>> My assumption was that recvfrom() and accept() should return sin6_flowinfo
>> from the received packet, and connect() and sendto() should take
>> sin6_flowinfo and put it into sent packets.
>>
>> For
In your previous mail you wrote:
My assumption was that recvfrom() and accept() should return sin6_flowinfo
from the received packet, and connect() and sendto() should take
sin6_flowinfo and put it into sent packets.
For bind(), I'd say either error if sin6_flowinfo is non-zero,
In your previous mail you wrote:
>more questions (I could not find answer from my archive):
>(4) what happens if we connect(2) with sin6_flowinfo filled?
>my guess is that sin6_flowinfo sticks into pcb, and
>will be attached to every packet we will sen
Rich,
>
> My assumption was that recvfrom() and accept() should return sin6_flowinfo
> from the received packet, and connect() and sendto() should take
> sin6_flowinfo and put it into sent packets.
>
> For bind(), I'd say either error if sin6_flowinfo is non-zero, or ignore
> sin6_flowinfo.
Original Message-
> From: Erik Nordmark [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 21, 2000 10:47 AM
> To: Jun-ichiro itojun Hagino
> Cc: [EMAIL PROTECTED]
> Subject: Re: sin6_flowinfo and sendto/recvfrom
>
>
>
> > >The conclusion: sin6_flowinfo mbz
>> >The conclusion: sin6_flowinfo mbz in recvfrom(), and may contain
>> >only class bits in sendto(). It is much more convenient to make with
>> >setsockopt() or ancillary data.
>My take it also that accept() should behave the same as recvfrom,
>since a native application might take the address r
hello,
>> (6) what is the endian of sin6_flowinfo?
>> I guess it is network byte order, since it appears on the wire.
>Doesn't the basic API say that everything is in network byte order?
>There used to be some macros to take apart the flowinfo into a tclass
>and a flowla
> >The conclusion: sin6_flowinfo mbz in recvfrom(), and may contain
> >only class bits in sendto(). It is much more convenient to make with
> >setsockopt() or ancillary data.
My take it also that accept() should behave the same as recvfrom,
since a native application might take the address retur
> more questions (I could not find answer from my archive):
> (4) what happens if we connect(2) with sin6_flowinfo filled?
> my guess is that sin6_flowinfo sticks into pcb, and
> will be attached to every packet we will send.
My assumption is the same as y
> hello, I'm having hard time trying to remember sin6_flowinfo semantics.
> RFC2553/2292 are not very clear to me. for example, could someone
> answer these questions?
> (1) on recvfrom, how sin6_flowinfo should be filled?
> (2) on sendto, how will the kernel interp
12 matches
Mail list logo
