Sam writes...
>Aaron Nabil writes:
>
>> 
>> Several people on the list have reported timeout problems 
>> with clients like Outlook when using tcpserver and qmail's pop3.
>> 
>> . . .
>> 
>> Something is wrong with tcpserver.
>
>Before you start making conclusions, try to actually look at tcpserver's
>source code.
>
>After the connection is received, tcpserver forks and execs the server, at
>which point the forked tcpserver ceases to exist.
>
>It would be rather impressive for tcpserver to affect an existing
>connection when it is no longer running.

Tcpserver sets up the environment, signal handling and masks, and 
creates the descriptors (and sets options on them) for the child.  It
_would_ be impressive for tcpserver to affect a forked and execed pop
connection, but that's hardly germaine.  To bugger up a pop session,
all the tcpserver has to do is pollute the signal environment, fail to 
set or clear some critical process limit, or mess up one of the 
descriptors it passed to the child in any one of countless ways.  It
would be a trivial patch to tcpserver to cause your popserver
sessions to magically self-destruct after being connected for 30
seconds (not withstanding that it would be "impressive for tcpserver 
to affect an existing connection when it is no longer running"), long
after tcpserver has forked and exec'd itself in oblivion.

The only two things I've noticed about tcpserver so far are that
this setsockopt call seems kinda risky (from having seen a few 
setsockopt implementations, I wouldn't be surprised if the call fails).

if (flagkillopts) {
  setsockopt(t,IPPROTO_IP,1,(char *) 0,0); /* 1 == IP_OPTIONS */
  /* if it fails, bummer */
}

I would have used the safer and undoubtably correct...

if (flagkillopts) {
  int opt = 0;
  setsockopt(t,IPPROTO_IP,1,&opt,sizeof(opt)); /* 1 == IP_OPTIONS */
  /* if it fails, bummer */
}

And that tcpserver, unlike inetd, doesn't attach stderr to the
network connection.  In fact all of the children inherit tcpserver's
stderr!  I don't see any obvious side-effect of this yet.

-- 
Aaron Nabil

Reply via email to