[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