Eric Rescorla <[email protected]> writes: >> The libc implementation won't work with unmodified applications, because >> it will break when sharing/passing/inheriting file descriptors across >> processes, a common pattern for Unix servers. >> > > Hmm... I've seen designs where this should work, for instance where > you dup the fds to point them to some intermediate location.
I'd like to see such a design. I'm sure you can get something to work with some application, but if the goal is all applications, then it's going to be pretty tricky. "dup the fds to point them to some intermediate location" sounds pretty dubious to me. For one thing the dup system call doesn't change what an fd points to. Now, if you mean point the file descriptors to some intermediary daemon, then you are getting closer to a daemon implementation, and by the time you fix it up, that's what you will have. But anyway not all applications are written in languages that use libc. Not all applications are dynamically linked. And not all C implementations use libc--the standard recognizes both "hosted" and "freestanding" implementations. A big potential use case for TCPINC is network file systems, which tend to be implemented with a freestanding C compiler and supply their own libraries. A daemon implementation would encrypt NFS traffic, while a libc implementation likely would not. This is not to say there isn't some valuable library-level use case for TCP-ENO. (In fact, that's partly why we left the door open to static ENO options with multiple suboptions from host B, about which you are skeptical.) I just don't think such an implementation will satisfy TCPINC. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
