[Serdev] tcp_send

Andrei Pelinescu-Onciul andrei at iptel.org
Sat Jan 27 07:57:39 UTC 2007


On Jan 26, 2007 at 17:20, Katty Xiong <cyyxiong at yahoo.com> wrote:
> 
> --- Andrei Pelinescu-Onciul <andrei at iptel.org> wrote:
> 
> > On Jan 26, 2007 at 09:42, samuel <samu60 at gmail.com>
> > wrote:
> > > In a recent post Andrei (please correct me if I'm
> > wrong) already
> > > noticed this and said it is on the TODO list.
> > > 
> > 
> > Yes, it's on my todo list (and since a very long
> > time  on the
> > sip_router/TODO list under the fd cache for tcp_send
> > name).
> > In fact (as the fd cache name implies) I want to do
> > more then this, I
> > want to cache the last used n fds in the sender
> > process (where n is
> >  a small number, like 4 or 5). Because of these I
> > would probably replace
> >  the close() in tcp main with shutdown().
> 
> As I can see from the code, fd is a field in 
> tcp_connection. So if tcp_send() knows the pointer of
> the tcp_connection, it aotomatically knows fd, right?
> Unless there are some cases that the the filed fd is
> removed in the tcp_connection.

tcp_conn->fd contains the fd of the tcp_read process that currently 
 "owns" the connection. This fd can be used by tcp_send _only_ if
 this is the same process as the tcp_read one. So tcp_send would first
need to find out if it's the same process.

There is already a a comment describing this in tcp_send() (after
get_fd:):
/* todo: see if this is not the same process holding
 * c  and if so send directly on c->fd */

If you want to say that we don't need the fd_cache for this case, you're
right. The fd_cache will help for processes that don't send messages on
connections they already own (and ser being a proxy, is more likely that
 more messages will get sent on not "owned" connections), in particular
 for tcp to tcp forwarding (packets comming for connection a must be
 forwarded on connection b => it will be much faster if process A will
 cache the fd for connection b and it will not have to ask for it
 everytime).


Andrei


More information about the Serdev mailing list