Re: quantity in send queue ?
Re: quantity in send queue ?
- Subject: Re: quantity in send queue ?
- From: Nicolas Berloquin <email@hidden>
- Date: Thu, 29 Apr 2004 01:32:52 +0200
first, thanks for your explaination. All those ramifications are
sometimes scary ;-)
That's part of the rush of programming :-}
yeah, when it starts working ^_^
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.
I forget - is this TCP or UDP? Trying to outsmart TCP is a waste of
effort, and generally doesn't do what you want. If it's UDP, no data
is stored in socket buffers - either it gets sent, or it gets dropped,
down in the driver layer.
this is TCP. I'm not completely sure that I'm trying to outsmart TCP.
The more I think about it, the more I think it would be convenient for
me to know when the send queue is empty.
I'll recap what I'm doing, and the general context:
I have n peers. I'm sending streams of data to each of them (and
receiving too, but that's another story).
I need to be able to set the max kb uploaded per second overall.
So my basic algorithm is :
divide the available rate by the number of peers, and by the amount of
time the loop
passes per second, and tell each peer that they can send
total/numPeers/times-per-second bytes.
Each socket is setup (right now) as non blocking. It would be very
inconvenient for me if the sockets were
blocking. Therefore, I only know when the TCP send buffer is full when
I get EWOULDBLOCK back from
my send() call. And at that time, their send queue is usually around 65
kbytes.
With such big buffers laying dormant, the potentiality of having a few
kb/s extra data is great, and
that's what I observe with bandwidth monitoring software: instead of,
say a max rate of 22kb/s, I
get 4-5 peaks over 32k every 30 secs.
So this led me into thinking that I needed to know, when I do my send()
(or even right before), whether
the previous slice of bytes was sent (otherwise, I can determine that
the send buffer will grow, and
give up on this peer for the current loop, then test next time around,
etc).
Hence my questions about knowing the amount of data inside the TCP send
queue, or whether
the send queue is empty.
Another possibility would be to know when the ACK is sent back from the
peer.
And I don't know how to do that with the technique I'm using.
(non-blocking socket, with send()).
I tried setting up some write callback, and setting a writeable flag to
false right after each write, only
to set it back to true in the callback, but I believe that I fall into
the same problem with data queued
up the TCP send buffer (my callback is called even if the buffer is
filling itself).
so now I'm stuck in a loop ;-)
thanks for your help !
_______________________________________________
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.