Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bryan
From: bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End)
Newsgroups: comp.sys.amiga
Subject: Re: Dnet:  Accessing your Amiga from a Unix host;  Mailchk
Message-ID: <455@mohawk.cs.utexas.edu>
Date: 14 Mar 90 02:20:07 GMT
References: <2472@quiche.cs.mcgill.ca>
Reply-To: bryan@cs.utexas.edu
Organization: Spam Detection & Removal Squad, Austin, TX
Lines: 30
Spam-Content: Negligible

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?