Subject: Re: TCP send buffer free space-Conclusion
To: None <tech-net@netbsd.org>
From: Scott Barron <sb125499@oak.cats.ohiou.edu>
List: tech-net
Date: 07/28/2001 12:28:26
Don't mean to reply to Dave via Mark's reply but I don't have the rest of the
thread.  Sorry.

Anyway, you can get the send/recv queue sizes and counts from the socket
structure's so_recv/so_snd members (which are struct sockbuf).  From there
sb_cc gives you the count in the buffer and you can make your priority
scheme based on this.  There could be some other members that you would be
interested in, look around in <sys/socketvar.h> for descriptions of each.

I'm going to go slightly off-topic for tech-net now, feel free to slap me
around and I'll take it to private email.  In order to create an optimal
solution to your problem (which shouldn't be *too* incredibly difficult) it
would probably be best to know the characteristics of the "Fast" and
"Important" streams.  Is fast a fairly constant stream of data while
important is more intermittent, vice versa, or are they about equal?  I've
given some thought (just a bit) to it if "Fast" is constant and "Important"
is intermittent.  I may be completely off here, but I'll give it a shot
anyway.  Here goes:

Move "Fast" to enter the app via a socket (as you said earlier).  Set up a
thread each for the incoming "Fast" and "Important" data streams.  Perhaps
with their own buffers, or whatever you need depending on the stream
characteristics.  Set up another thread that will "manage" the socket (using
the send queue information, etc.)  Then set up a lock that prevents "Fast"
from sending data to the manager thread.  When "unlocked" "Fast" can send
out.  If "Important" has data it will lock and send out, or if the manager
thread deems that the send queue is getting too small it can lock "Fast"
from sending until the queue size is reasonable (effectively always keeping
some space free for "Important" data in the queue).  What this magic size
might be, I don't know, it would probably take some testing to get it optimal.

I noticed you work at GRC.  I'm a summer intern there (Mark knows who I am),
perhaps we've met (SRG?).  Anyway, I generally find myself not always clear on my
explanations so if I wasn't clear I'd be more than happy to discuss it
further in person.

-Scott


On Fri, Jul 27, 2001 at 08:43:51PM -0400, Mark Allman wrote:
> 
> > - Do some "kernel grovelling" to find out the Send Buffer free
> > space. I don't want to go this deep to get the information,
> > because I'm pretty sure I'd somehow screw things up and cause
> > myself myriad other problems
> 
> Ah, so a thought...  (maybe already voiced -- I lost the bubble on
> this thread).
> 
> I think netstat will report on the status of the buffer.  Grab the
> code and see how they do it.  Likely they dig around in the kernel
> memory.  But, if they already have a method of doing it that you
> could integrate into your app the chances of busting things wlll go
> down.
> 
> allman

-- 
"as we enjoy great advantages from the inventions of others, 
we should be glad of an opportunity to serve others by any invention 
of ours; and this we should do freely and generously."
--Benjamin Franklin