On Mon, Oct 1, 2012 at 8:14 AM, Roy Smith <r...@panix.com> wrote: > Yeah, that's a problem. There's nothing fundamental about a TCP > connection endpoint which precludes it being serialized and passed > around. The amount of state involved is pretty small. Unless I've > forgotten something, 2 IP addresses, 2 port numbers, a few bits worth of > TCP protocol state, and, for open connections, 2 sequence numbers. > Maybe a couple of timers, but I don't think they're strictly necessary. > The problem is, most of that state is private to the kernel.
And can change at a moment's notice, with no userspace interaction. The socket connection also needs to retain sent-but-not-acknowledged and received-but-not-in-order data, so those buffers need to exist. The only way would be for the kernel to export something representing a socket - which would be the file handle. And then you have to worry about any other state, eg if you're reading line by line and are retaining a partial line... not really something that can be patched in five seconds, and not IMHO worth trying to do. Easier to simply retain the process ID. Oh, and if the pid changes on a live connection, what will that do with iptables controls, which can look at the originating process's user id and such? Hrm. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
