RE: Rfcomm Use Count

Hi Marcel,

> > I just tried an experiment where I listen for a while before calling
> > accept(). I can raise the use cound by connecting, 
> disconnecting, etc (as
> > before). As soon as accept() is called, the excess use 
> count goes away.
> > 
> > Before accept() is called, the server will start refusing 
> connections after
> > you fill up the accept queue. The queue is emptied with a 
> single call to
> > accept().
> 
> so this means when we disconnect we must ensure that we also 
> remove this
> connection from the accept queue if it is pending there.
> 
> What I know think is that calling the bt_accept_unlink() function only
> from bt_accept_dequeue() is wrong. If bt_sk(sk)->parent is set and we
> ran into a disconnect then we must unlink it by ourself. Does 
> this make
> sense?

This makes sense to me, but I'm not convinced that it's enough of a problem
to warrant major changes. And I'm probably not the best person to ask. ;)

Do we know how the tcp stack handles this kind of thing? (I had a quick look
at a text on sockets and it didn't specifically cover the case of
connections getting closed which are in the queue. But it was clear that the
precise behaviour of the queue varies for tcp-ip from unix to unix.)

Most servers (I think) would sit with accept() blocking and then spend a
very brief time handing off the new connection before blocking on accept()
again. So this wouldn't cause much trouble.

I suppose this could affect a very simple server which is single-threaded
(and so could spend significant time between accept() calls). Or a very busy
server. I'm not sure that this is really a major issue for bluetooth (the
bandwith and number of real connections is quite limited compared to
tcp-ip).

-Daryl.



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php