V Guruprasad wrote: >On Tue 2002.11.05, John Stracke wrote: > >>The problem is that only the app knows what kind of caching behavior it >>needs. For a simple protocol like SMTP or HTTP, pure DNS-based caching >>is fine; for a more sophisticated protocol (e.g., any sort of >>videoconferencing app), it may be necessary to ensure that each >>connection associated with a given session go to the same address. >> >> >I see both as largely system calls API issues, permitting simple and >elegant solutions, and as not fundamental networking constraints that >would legitimately rule against the INFS approach. > I disagree. The answers you give seem to say that you assume there are only a few possible variations on an application's needs, which is not the case. >As Vahalia (Unix internals book) describes, different network filesystems >involve very different caching behaviours, meaning that the VFS name tree >cache already caters to a wide variety of desired behaviours. The Linux VFS, >for example, provides for per-node ttl, and can be manipulated on a per- >process basis by setting mode parameters specifying the cache control >before "opening" the nodes. > (a) This requires that the kernel be able to support the cache logic that the app needs. The only way to support apps with novel requirements is a minimalist API on which the app can build its own logic. That's the lesson of Unix--and, for that matter, of IP. (b) Per-process is not sufficient, because a given process may need several different styles of caching. For example, consider a conferencing program with an embedded LDAP client. >For the second requirement, a simple known approach is to pass the already >open (socket) file descriptor as argument when opening the secondary >connections, so that the fd serves as an abstract handle for the previously >obtained address. > That works only if the first connection is still open. In addition, not all applications use connected sockets. If you're using a UDP-based protocol, it may be more efficient to have a single unconnected socket, and specify the recipient address on each packet you send. This is especially true for servers; if you've got lots of requests coming in, and they don't require a lot of user-space CPU, then the cost of creating a new socket for each request could add significantly to the cost of serving the requests. >>The fixed-length numeric addresses still need to exist, and their nature >>still needs to be coded into all hosts and routers. Hiding them from >>the apps will not make it easier to upgrade the installed base. >> >> > >No, but it would avoid inertia from the apps, whose hardcoding for IPv4 >sockaddr's does pose some problems for v6 migration and dual support >in wireless devices and appliances. > And you think you won't encounter inertia trying to get people not to use sockaddrs at all? >The sub-problem of preserving TCP connections has been variously addressed >in other scenarios, e.g. in Snoeren and Balakrishnan's Mobicom'00 paper. >There are TCP protocol extension proposals to allow renumbering of end points >within the connection. > Securely? And what about all the non-TCP-based protocols? -- /===============================================================\ |John Stracke |jstracke@centivinc.com | |Principal Engineer|http://www.centivinc.com | |Centiv |My opinions are my own. | |===============================================================| |If you're going to walk on thin ice, you might as well *dance*!| \===============================================================/