[drats_users] D-RATS questions, suggestions

[Dan Smith]

Hi Brian,

Thanks for taking these to the mailing list. Sorry for the delay in
responding.

> 1) It would be VERY helpful if the "Stations" screen on the right 
> side of the Chat tab reflected stations on a particular Chat channel 
> ONLY (when viewing a Channel tab).

Well, there are a couple of problems with that. First off, nobody is
ever really "in" a channel, nor are channels private in any way.
"Joining" a channel is really just choosing to receive messages tagged
as being for that channel. Sure, I could have each station broadcast
which channels it was monitoring periodically so that everyone could
update their list. However, that would just further add to the chatter
on the (RF) channel. I'm not sure it's worth that -- it's 900 baud after
all :)

> 2) In the log screen, when filtering for file transfers, it would be 
> nice if a file transfer log listing also included the callsign of 
> whoever grabbed a file from my "Shared" folder.

Indeed, noted, thanks :)

> 3) Is there any reason why transferring files via internet can't 
> occur at internet speeds?

Well, two stations connected to a ratflector will transfer at "internet
speeds", technically. However, the reason it doesn't seem that way is
because D-RATS does all the framing and flow control over the network
channel just as it would over the serial channel. This is highly
inefficient, as I think you understand based on your point about the
block size.

The problem lies in *knowing* whether you're talking to another station
that is reachable entirely via conventional network paths or not. That
means that there has to be some sort of path discovery between the
sender and receiver to determine if they are separated by any serial/RF
links (just knowing if they're both receiving each other via a network
path is not enough).

It's possible to add this, it's just not high on my list. I designed
(and intend) D-RATS to be a solution for making the RF channel useful.
Getting too far into making it a general-purpose internet chat, file
transfer, and messaging client is beyond the scope of what I'm
interested in.

> 4) I noticed, when sending multiple NTS forms in version 0.3.3, that 
> after I click on "Send" within the message screen, the message(s) 
> isn't actually sent.  I have to secondarily click "Send/Receive" on 
> the main program screen before the message actually gets sent.

You don't if you have automatic message forwarding enabled.

> Additionally, if I have multiple messages queued up for sending, I 
> need to click "Send/Receive" for each message in the queue before 
> each is sent individually.

Hmm, no, that shouldn't be the case. Is anyone else seeing this behavior?

> It would seem that the "Send" within the message screen would be 
> sufficient, and that multiple messages in the queue would be sent on 
> their way automatically.

Well, remember that slow-speed D-STAR is a voice *and* data mode. That
means that it's often desirable to queue one or more messages until
there is a lull (or explicit halt) in the voice traffic. For situations
where the data channel is dedicated, the automatic forwarding should do
what you want.

> 5) We recently set up a ratflector here in New Mexico and our
> initial testing revealed that, if a ratflector went down temporarily,
> then any D-RATS user out there who was connected to it would manually
> have to reconnect to it.

It should attempt to reconnect several (10, IIRC) times before giving
up. How long was it really down? Yes, I suppose I could make it try forever.

> I can see a situation where a user, perhaps in an ARES tactical net,
> might not be aware that his connection was lost and might
> consequently miss out on important action.  Is there not a way for
> the D-RATS application to sense that a connection has been lost and
> automatically reconnect?  It could be as simple as, when D-RATS
> hasn't seen data from a ratflector for n-minutes, the D-RATS 
> application sends a ping or keep-alive message to the ratflector.

This is generally the responsibility of the operating system (and the
TCP stack). If your ratflector went down and came back up at a different
address, it's likely that your OS would keep attempting to salvage the
connection for quite a while before giving up.

Yes, I could make D-RATS attempt to be more aggressive about this.
Again, I'll point to the focus on the RF side of things as my excuse for
why this isn't more robust. The network functionality started out as a
way to remotely-locate the radio for one or more users in a closed
system. It expanded to the internet "ratflector" idea simply as a way to
allow folks to play with D-RATS before taking the plunge on an actual
piece of hardware. It has clearly taken on a new set of users who want
it to do more than that. I'll draw the line with my personal interest at
making D-RATS into an internet-only or internet-focused application.
There is a lot of (much better suited) software for that sort of thing
out there!

Patches are always gladly accepted, of course :)

-- 
Dan Smith
www.danplanet.com
KK7DS

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
Url : http://intrepid.danplanet.com/pipermail/drats_users/attachments/20121116/41ad894d/attachment.bin