[Dxspider-support] client

[Dirk Koopman]

On 28-Mar-2000 Steven Franke wrote:
> Ah, that did it. I had set $clusteraddr to the hostname. When I changed it
> to "localhost", client worked just fine. Thanks!

***************** NB ************************

You should *ONLY* change $clusteraddr if you need to allow clients on OTHER
MACHINES access directly (in internal (undocumented) DXSpider protocol).

You should *ONLY* change $clusterport if it clashes with something else (very
unlikely).

*********************************************

The only reason you would actually change $clusterport and thus use -h on the
new client is if you are running some kind of network cluster of machines with
radio and other ports distributed amongst them such that it appeared to the
outside world as one big cluster node. This would allow them all to
communicate via ethernet IP addresses - the downside of this is that you
would (ideally) need to make sure that only those machines could communicate
and not some nasty hacker... [you ARE NOT running cluster.pl as 'root' ARE
YOU?].

For nearly all applications where the radio ports are on the machine running
the node (and/or is running ethernet or other connections to a flexnet or bpq
node) - you leave these two values well alone.

In the fullness of time I will parse DXVars.pm for these values but I need to
get the functionality right first. 

With that in mind, there will be a 1.39a patch out shortly with a new drop
of the C client which has login implemented and ax25 buffering done hopefully
better.

Dirk G1TLH

> 
> On Tue, 28 Mar 2000, Dirk Koopman wrote:
> 
>> What have you set $clusteraddr and $clusterport to in DXVars.pm?
>> 
>> You will need to add a -h<clusteraddr> and -p<clusterport> to the command
>> line
>> if you aren't using the the standard values of localhost and 27754
>> respectively.
>> 
>> Dirk G1TLH
>> 
>> On 28-Mar-2000 Steven Franke wrote:
>> > The C client seems to compile fine here, but an attempt to run it from
>> > the
>> > command line results in an error and a segmentation fault, e.g.:
>> > 
>> > /spider/src> ./client k9an-7
>> > Error on connect to localhost port 27754 (111)
>> > Segmentation fault      
>> > 
>> > I guess it's working OK for others, so does this mean I have something
>> > configured wrong here?
>> 

-- 
Dirk-Jan Koopman, Tobit Computer Co Ltd 
At the source of every error which is blamed on the computer you will find
at least two human errors, including the error of blaming it on the computer.