lobster@quiche.cs.mcgill.ca (Stephane LAROCHE) (03/14/90)
I have seen in the past some questions about using DSOC or PUTFILES
(in fact any unix client) from a Unix host with the latest version of
Dnet (2.10.13 ?). People have noticed that they could used dsoc from an
fterm, but not from another terminal. Well, I have just discovered
recently that setting the environnement variable DNETHOST to ' ' (1
blank) or to '3', depending on your socket name in DNETDIR solves the
problem. Maybe Matt could tell us why this is necessary ?
I posted recently a mail server in comp.sources.amiga. I now have a
new version which uses the SPEAK: device and will work on any BSD Unix
or Sun OS. As I have no idea how much persons is using MAILCHK, it's
probably better to mail me that you are interested. If there is enough
interest, I'll post it...
#########################################################################
Stephane Laroche
Live long and prosper !
lobster@calvin.cs.mcgill.ca
#########################################################################bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End) (03/14/90)
In article <2472@quiche.cs.mcgill.ca> lobster@quiche.cs.mcgill.ca (Stephane LAROCHE) writes:
=-
=- I have seen in the past some questions about using DSOC or PUTFILES
=-(in fact any unix client) from a Unix host with the latest version of
=-Dnet (2.10.13 ?). People have noticed that they could used dsoc from an
=-fterm, but not from another terminal. Well, I have just discovered
=-recently that setting the environnement variable DNETHOST to ' ' (1
=-blank) or to '3', depending on your socket name in DNETDIR solves the
=-problem. Maybe Matt could tell us why this is necessary ?
=-
Wow, telepathy. I just decided to look into this long (well, since
December)-problem, and came to the same conclusion. There IS a bug somewhere
though. Here's the problem: all this host stuff is currently unimplemented,
so dnet just defaults to a host ID of '3' (don't ask me why). dsoc tries to
connect to the socket DNET.x in $DNETDIR, where x is either the value of
$DNETHOST, or 3, if $DNETHOST is not set. Fine. However, DNet creates a socket
named 'DNET. ' instead, even though the code in dnet.c (function setlistenport)
*looks* like it should create DNET.3 (the '3' is currently hardcoded). This
same function also sets $DNETHOST to the name of the socket it created, so
everything is fine within the environment of the original DNet process. Now,
if you try dsoc from some shell that didn't inherit its environment from the
DNet process, then $DNETHOST is not set. Thus, dsoc (correctly) tries to
connect to the default socket, DNET.3, and can't find it. Barf.
As you said, the workaround is to put "setenv DNETHOST ' '" in your
.login.
I stared at dnet.c for an hour today, and cannot see any reason why the
socket that gets created is named 'DNET. ' instead of DNET.3 . Can anyone
enlighten me?kent@swrinde.nde.swri.edu (Kent D. Polk) (03/15/90)
In article <455@mohawk.cs.utexas.edu> bryan@cs.utexas.edu writes: >In article <2472@quiche.cs.mcgill.ca> lobster@quiche.cs.mcgill.ca (Stephane LAROCHE) writes: >=- >=- I have seen in the past some questions about using DSOC or PUTFILES >=-(in fact any unix client) from a Unix host with the latest version of >=-Dnet (2.10.13 ?). People have noticed that they could used dsoc from an >=-fterm, but not from another terminal. Well, I have just discovered > >*looks* like it should create DNET.3 (the '3' is currently hardcoded). This >same function also sets $DNETHOST to the name of the socket it created, so >everything is fine within the environment of the original DNet process. Now, >if you try dsoc from some shell that didn't inherit its environment from the >DNet process, then $DNETHOST is not set. Thus, dsoc (correctly) tries to >connect to the default socket, DNET.3, and can't find it. Barf. > As you said, the workaround is to put "setenv DNETHOST ' '" in your >.login. Hmmm, I had noticed that the latest version of Dnet DOES create a 'DNET.3', but the previous just a 'DNET.'. With the proevious version, all worked fine, but with the new, servers couldn't be found, etc. Essentially all I could do was to connect an fterm. Anyway, I changed DNETHOST to ' ' and to 3, for the previous version, and PRESTO, it fails in exactly the same way as the latest version of DNET! (Does this just confuse the issue, or what?) ==================================================================== Kent Polk - Southwest Research Institute - kent@swrinde.nde.swri.edu Motto : "Anything worth doing is worth overdoing" ====================================================================
stroyan@hpfcso.HP.COM (Mike Stroyan) (03/15/90)
> I stared at dnet.c for an hour today, and cannot see any reason why the > socket that gets created is named 'DNET. ' instead of DNET.3 . Can anyone > enlighten me? The "DNET. " is coming from the amiga side. In control.c, do_cmd is sending a PKCMD_ACKRSTART packet with a space character. That is processed on the unix side by do_cmd in the unix control.c. It calls setlistenport with the data character sent by the amiga. The bind in setlistenport then appends the space to "DNET.". Mike Stroyan, stroyan@hpfcla.hp.com
bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End) (03/15/90)
In article <9010010@hpfcso.HP.COM> stroyan@hpfcso.HP.COM (Mike Stroyan) writes:
=-> I stared at dnet.c for an hour today, and cannot see any reason why the
=-> socket that gets created is named 'DNET. ' instead of DNET.3 . Can anyone
=-> enlighten me?
=-
=-The "DNET. " is coming from the amiga side. In control.c, do_cmd is sending
=-a PKCMD_ACKRSTART packet with a space character. That is processed on the
=-unix side by do_cmd in the unix control.c. It calls setlistenport with the
=-data character sent by the amiga. The bind in setlistenport then appends
=-the space to "DNET.".
=-
Aha. I see it now. I guess I was misled by the fact that
setlistenport is not declared as external anywhere. Tsk tsk. That still
leaves an inconsistency, though. Presumably the hardcoded '3' should be
changed to a ' ' everywhere. Geez, Matt, at least use #defined constants in
situations like this! Better yet, I suppose the -n option for dnet is supposed
to supply this, whenever it finally starts being used.