RE: Asynchronous sock_sendmbuf
RE: Asynchronous sock_sendmbuf
- Subject: RE: Asynchronous sock_sendmbuf
- From: "Eddy Quicksall" <email@hidden>
- Date: Wed, 21 May 2008 14:56:35 -0400
I just noticed you are looking at sock_sendmbuf, I'm using so->so_send
(sosend).
Eddy
-----Original Message-----
From: darwin-kernel-bounces+quicksall_temp=email@hidden
[mailto:darwin-kernel-bounces+quicksall_temp=email@hidden]
On Behalf Of Eddy Quicksall
Sent: Wednesday, May 21, 2008 2:00 PM
To: 'Igor Mikushkin'; email@hidden
Subject: RE: Asynchronous sock_sendmbuf
On BSD4 you will get an up_call with the sends. I'm not sure which version
Apple is using but I would expect that the up_call is still the same.
As pointed out by your reference, asynchronous I/O is preferred for high
performance. If your app is not high performance, the I would not try to use
it. In my case, I need the performance.
To tell when your send is complete, you can record the sequence number when
you open your socket (inpcb->snd_una). For each send you can calculate the
expected sequence number by adding the last one you calculated to the length
of your send; that number represents the ACK for that complete send. In the
up_call, compare the calculated sequence number with the sequence number
given in inpcb->snd_una. If that is >= the computed one then your send is
complete.
tcpcb = ((struct tcpcb*)(sotoinpcb_hdr(so)->inph_ppcb));
The problem I have now is, how do I tell that the connection get a RST or
FIN from the up_call.
At least this is true for BSD4. I would give it a try.
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: Wednesday, May 21, 2008 6:30 AM
To: email@hidden
Subject: Re: Asynchronous sock_sendmbuf
First of all, thanks to all who answered.
I have carefully read all of the answers and I'm trying to figure out
some points now:
1. What events?
I can't see somewhere a list of events, for which upcall function
will be invoked.
Unfortunately ADC documentation seems to be incomplete (see
http://developer.apple.com/documentation/Darwin/Reference/KPI_Reference/kpi_
socket).
"Your upcall function will be called when:" is the last line in
this document.
I have downloaded xnu-1228.3.13 and I'm looking it through now.
2. Blocking vs. non-blocking?
Josh Graessley wrote:
> The only difference between blocking and non-blocking is that
blocking will block and wait if there is no space available in the
send queue
Frankly speaking it is a surprise for me, I supposed that write
function for blocking socket returns only when an operation (sending)
is actually completed.
Anyway, I suppose blocking does not work for me.
I'm writing a driver that process read / write routines from a
file system context, so I think blocking can be dangerous here.
Network Kernel Extensions Programming Guide says here:
If your code is in a performance-critical part of the kernel (as
opposed to a call from user space), you should generally perform
socket I/O asynchronously.
Moreover I think mbuf part of code must be non-blocking too
(according to this document).
3. If I get EWOULDBLOCK status from sock_sendmbuf?
What does EWOULDBLOCK status of send operation exactly means?
At the moment I suppose it means that there are no enough memory
in send buffer.
So I just should retry later, yes?
4. Blocking?
I can use blocking sockets in a separate thread anyhow.
Is using blocking sockets with an upcall function correct in general?
5. Should I get to know when a send operation actually completes?
I think a general answer is no.
When sock_sendmbuf returns I should think that the operation is done.
6. Upcall
First invoking of the upcall routine is related to sock_connect
(no matter blocking or non-blocking).
Then I should try to read at any upcall.
Am I right?
7. Mbuf
The ADC example
(see
http://developer.apple.com/documentation/Darwin/Conceptual/NKEConceptual/Soc
ketManipulation/chapter_3_section_3.html#//apple_ref/doc/uid/TP40001858-CH23
5-DontLinkElementID_4)
does not free mbuf in the upcall routine.
Is this a bug or a special case (related to upcall)?
Sorry for so long message,
Thank you very much for reading it.
Please correct me if I'm wrong somewhere.
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:
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