#define SO_NWRITE
0x1024 /* APPLE: Get
number of bytes currently in send socket buffer */
Are you saying I would wait for an up_call that shows no bytes left in
the buffer? If so, what about the bytes that have not yet been moved from my
user buffers to the mbuf's?
It would probably be safe to consider the so_send complete after all
bytes have been transferred to the internal buffers but this does not seem to
give me that information.
Another question: If I have back-to-back asynchronous calls to so_send
will they all be transmitted?
Eddy
-----Original Message-----
From: Josh Graessley [mailto:email@hidden]
Sent: Tuesday, May 20, 2008 11:52 AM
To: Eddy Quicksall
Cc: 'Igor Mikushkin'; email@hidden
Subject: Re: Asynchronous sock_sendmbuf
You're probably better off using the socket option that gives you
the
amount of data in the send buffer. I believe it's called
SO_NWRITE
(corresponding to SO_NREAD).
Accessing the tcpcb like that is against the rules for a well
behaved
kext. Your kext may break with any release where the tcpcb or
layout
of the socket structure changes.
-josh
On May 20, 2008, at 5:40 AM, Eddy Quicksall
wrote:
> I'm doing the same thing (see thread "Use of asynchronous
receive at
> kernel..." on this list). Maybe we can help each other out.
>
> The unfortunate thing about the up_call is that it does not tell
you
> what it
> is for. The up_call can happen with a lot of different cases,
accept
> is just
> one ... there is send, recv, RST, FIN and probably even more.
>
> My current problem is the same as yours. How do I tell when a send
is
> complete? Here is my plan. I will be trying it this morning:
>
> 1. When I accept the connection, I will retrieve the current
> sequence number
> and save it in my personal socket structure. Then save a pointer
to
> the
> personal structure in so->so_upcallarg. Call this sequence
number
> seq_no.
> 2. Each time I begin a so_send, I'll increase seq_no by the bytes
in
> the
> so_send. I'll save this new number in a structure related to
the
> data to be
> sent.
> 3. When I get an up_call, I'll get the next un-acknowledged
sequence
> number
> and check it against the expected sequence number in step 2. If
it
> is >=
> then it means that so_send is complete.
>
> Here is how to find the sequence numbers (at least for BSD4):
>
> tcpcb = ((struct
tcpcb*)(sotoinpcb_hdr(so)->inph_ppcb));
>
> tcpcb->snd_una is the next un-acknowledged sequence number.
>
> There is one catch to this and that has to do with timing. When
a
> connection
> is accepted a syn is sent and that accounts for one sequence
number.
> If the
> syn has not been acked then snd_una will not be advanced. We need
to
> know
> what the next sequence number is for the above computations. There
is
> another thing called snd_nxt which is the sequence number of
next
> byte to be
> sent. So to initialize the seq_no in step 1 it is best to
use
> snd_nxt since
> you can't be guaranteed when the outgoing syn is actually
acknowledged
> (although it will be very quick).
>
> Eddy
>
> -----Original Message-----
> From:
darwin-kernel-bounces+quicksall_temp=email@hidden
>
[mailto:darwin-kernel-bounces+quicksall_temp=email@hidden
> ]
> On Behalf Of Igor Mikushkin
> Sent: Tuesday, May 20, 2008 3:55 AM
> To: email@hidden
> Subject: Asynchronous sock_sendmbuf
>
> Hello!
>
> I'm using non-blocking sockets.
> I couldn't find a way to get to know the result of send operation.
> If I understand correctly upcall callback is called only when an
> incoming data is available (I do not talk here about listen /
accept).
>
> So is there any way to get to know if my send operation is
completed?
>
> What is EWOULDBLOCK status for in sock_sendmbuf?
> What does it mean?
>
> Thanks.
>
> Best Regards.
> Igor
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Darwin-kernel mailing list
(email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> uth.net
>
> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Darwin-kernel mailing list
(email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
>
> This email sent to email@hidden