Re: quantity in send queue ?
Re: quantity in send queue ?
- Subject: Re: quantity in send queue ?
- From: Bryan Christianson <email@hidden>
- Date: Thu, 29 Apr 2004 07:29:03 +1200
At 7:46 PM +0200 4/28/04, Nicolas Berloquin wrote:
int error = ioctl(s, TIOCOUTQ, &value);
- in this case, we're lucky. IOCTLs are specific to parts of the
"I/O subsystem". Commands of the form TIOC* (or those using
't' in their definition) are specific to the terminal subsystem.
For sockets, you want things of the form SIOC*.
And, finally, I don't know of a "good" way to find out what is in
the transmit queue for your socket. Commands like 'netstat' can
get this information, but they do it by (a) running as root; and
(b) copying up the socket structure from the kernel, and
interpreting the information in that structure.
One can get the count of bytes queued to be read, but not sent.
Generally, this is an uninteresting number. What are you trying to
achieve? There may be another (better) way to get there.
first, thanks for your explaination. All those ramifications are
sometimes scary ;-)
This is related to my previous discussion about throttling.
If, when I'm about to send some data to a remote peer, I can know
that there is still
some data inside its send buffer, then I will postpone my send()
until the next loop.
From the way I looked at it, it seems the easiest way to handle my
bandwidth problem.
But maybe I could achieve this by setting the send window size by
hand to the amount
previously sent and therefore expecting a EWOULDBLOCK if the data
wasn't already sent.
Otherwise, all the 65k are filled and I never know when they are
really sent to the peer.
(I'm usually sending amounts < 1k).
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.
Unless you are trying for some very very high accuracy in this, I
would suggest you look at a token bucket type bandwidth allocation.
It is relatively simple to code, and as Peter pointed out in an
earlier post, TCP is adaptive and will adjust to match your bandwidth
constraints, thus keeping the send queue at a tolerable level. With
careful tweaking you can get this scheme to perform within 1 or 2 %
of your nominal constraints
Google will reveal details of the algorithm = heaps of sample code available.
--
Bryan Christianson
email: <
mailto:email@hidden>
Home Page: <
http://crash.ihug.co.nz/~bryanc>
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.