[Dxspider-support] "you are connected to me" Problem

[Ron Stordahl]

There are a number of problems here.  The main one is the apparent fact 
that if you lose your telnet connection this fact is not immediately 
signaled to dxspider.  Since telnet is a connected protocol certainly it 
must have the capability to do this, then dxspider could drop the 
connection immediately and when the user tries to reconnect with the 
same call-ssid he will be able to do so.  At one time I looked at the 
registry settings regarding tcp and I think there is a setting in there 
for 'keep alive' but it is at some insane value like 7200000 
milliseconds (2 hours!)  But the user program (in this case dxspider) 
can call a routine to adjust it downward...maybe 30 seconds would be 
more like it?  Now I am not sure that this is the parameter of interest, 
but this might give you an idea of what to do so that disconnects are 
promptly signaled to dxspider so it can take appropriate action.

The second problem is the question of user filter settings (maybe all 
settings) associated with different (0 thru 15) SSID's of the same 
call.  I don't know what was the motivation, but in AR-Cluster CALL-SSID 
for 0 thru 15 all have the same user settings.  That was actually a 
problem in some cases, and so AR-Cluster allowed higher SSIDS (16 and up 
to some value unknown to me  - of course only via telnet ), the 
characteristic being that that set of SSIDS's (maybe all of them as a 
group 15) can have a set of user characteristics different from the 0-15 
group..  I would say it was a kludge..but a needed one.

Since you consider SSID's (0 - 15 ) all as distinct there would be no 
need to do the greater than 15 trick in dxspider as long as disconnects 
were quickly dealt with.

If telnet would promptly signal a disconnect then Lee VE7CC might not 
need to have his program generate new SSID's for automatic reconnect either.

Ron, N5IN

Dirk Koopman wrote:

>>One thing that Spider does that I don't like is that it treats all these
>>SSIDs are completely separate users.  They have to log in and resend all
>>their information.   The big problem is that the filters don't carry
>>over from one SSID to the other.  In AR Cluster the filters are carried
>>from one SSID to another, unless the SSID is over 15.  That is why you
>>occaassionally see AR Cluster users with SSIDs of -16, -17 etc.
>>    
>>
>
>Now this is a long standing gripe that many people have had, but I have
>several problems with doing it differently.
>
>Firstly a callsign is treated as a unique (primary) key on a node. It
>would be *very* inconvenient for me if this was to be changed. It makes
>everything very much more complicated. There is a further, important
>issue for node operators: most parts of the world you don't have the
>(in)convenience of a completely separate callsign for the node (eg, for
>me, GB7DJK/GB7TLH for the nodes and G1TLH for me). So you have to run it
>under some version of your callsign. In order for the unique key to
>operate then you will need either to run the node with <call>-<ssid> and
>the sysop alias as <call>, or the other way around.
>
>I also reckon that other software would get a bit confused if you appear
>as node one minute and a user the next, then keep swapping.
>
>It could all be fixed of course, it is just a load of work and testing.
>
>However, I will take on board your remarks about cloning user data from
>the non-ssided call onto ssided ones. 
>
>The real question is: if I allow bumping of existing users (so people
>could reconnect with the same callsign) would all this problem with
>ssids still exist to the same extent?
>
>Dirk
>
>
>_______________________________________________
>Dxspider-support mailing list
>Dxspider-support at dxcluster.org
>http://www.tobit.co.uk/mailman/listinfo/dxspider-support
>  
>