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(_at_)centivinc(_dot_)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*!|
\===============================================================/