Menu
▾
▴
#220 comm - use canonical ids for remote host connections
Hi,
The comm man page mentions the following limitation:
---------
WARNING: The host must always be specified in the same
form (e.g., as either a fully qualified domain name,
plain hostname or an IP address).
---------
I use {<port> <hostname>} to connect to the remote comm
channel. However, the id listed on the remote
interpreter is of the form {<port> <hostip>}. As a
result, it ends up creating one extra channel for
communication between remote hosts. See below:
# Host1 = mavis
mavis:219> wish
% package require comm
4.2.1
% comm::comm config -local 0
% comm::comm self
40048
% hi <----- "hi" printed from "hlavana-u5" below
comm::comm ids
40048 {32807 64.102.40.12} <--- remote id uses ipaddr
% comm::comm send {32807 hlavana-u5} {puts hi}
% comm::comm ids
40048 {32807 64.102.40.12} {32807 hlavana-u5}
%
# Host2 = hlavana-u5
hlavana-u5:52> wish
% package require comm
4.2.1
% comm::comm config -local 0
% comm::comm self
32807
% comm::comm send {40048 mavis} {puts hi}
% comm::comm ids
32807 {40048 mavis}
% hi <---- "hi" printed from "mavis" host
comm::comm ids
32807 {40048 mavis} {40048 64.102.16.217}
%
For the above case, I would expect the [comm::comm ids]
command to return exactly the same values in both the
interpreters once the connection is established between
the two -- something like:
{32807 hlavana-u5.cisco.com} {40048 mavis.cisco.com}
In addition to the above issue, the $id value set for
the callback hooks are also not consistent. So, the
comm package should be enhanced to remove this
limitation and always use the canonical id internally.
It should not differentiate between whether the id is
specified simply as "40048", or "40048 localhost", or
"40048 mavis", or "40048 mavis.cisco.com", or "40048
64.102.16.217".
Note that the [comm::comm self], [comm::comm ids] and
$id variable set for callback hooks should return the
cannonical forms of the id.
Hemang.
Logged In: YES
user_id=75003
Looked a bit into this. When the remote interpreter receives
an incoming connection it calls the commIncoming callback
for the listening socket. The second argument is the ip
address of the host the connection is coming from. That is
the reason for the use of an ip address instead of a
hostname. The remote interp has nothing else.
Tcl is asymmtric in this regard. The side opening a
connection can use ipaddr or hostname, and Tcl will use the
OS to resolve hostnames to ip. The remote side however has
only the ip address, not a hostname, and Tcl does not do
reverse resolution. Note also that the revers lookup is also
not unambigous. We may have several hostnames for an ipaddr.
To get the hostname either the host opening the connection
has to send its name as part of the first message, like it
already does for offered protocol versions, or the remote
host has to perform some sort of reverse dns lookup (ip ->
hostname).
The first is possible, means that the protocol goes a
version higher. Disadvantage: The name as send may not be
visible as is in the DNS of the remote host. Meaning that
trying to connect back to that will fail. This will likely
work best if both hosts use the same dns server. Not in
general however.
And reverse dns lookup, well, that is neither built into
Tcl, not do I remember a package which could do it. Maybe
tcllib::dns ? No idea. That has the disadvantage that the
reverse lookup takes time, i.e. more time until the
connection is open.
The id value for the hooks is likely depending on whether
this is a 'local' or a 'remote' hook. The remote hooks do
not have host names, the 'local' hooks use whatever id the
user specified when the connection was opened.
There is definitely no quick, easy, and full solution for
this (pick two).
Well, the protocol extension maybe, with a quick check if
the received name can be resolved. If not then fall back to
the regular behaviour.