¿ªÔÆÌåÓýBy default, the acknowledgement that you see on each key up is from qnlink. It's just reminding you that you are not linked. Just as a quick reminder, when you are linked, there is a state maintained by both the server and client. This state is effected by a constant ping-ponging going on between the client and server. If either server or client drops, the other will find out fairly quickly. Routing is different. There is no state maintained by either the client or server. The QuadNet Routing Group web pages logs subscription and unsubscription events for Smart Groups, but not for legacy STARnet groups. Once logged into Smart Group, the server will maintain a keep
alive ping to the clients (no pong from the client is returned)
but that pinging is strictly for keeping a client's fire wall
open. (This is how Colby and I figured out how to make group
routing work with mobile clients.) It has nothing to do with
maintaining a connection state. A routing group has no idea if a
client is still listening. That's why routing groups (both Smart
Groups and STARnet Groups) have client timeouts. Because there is
no state maintained, there has to be some "drop dead" time when
the server assumes the client is no longer there. It would be extremely difficult to teach QnetGateway to maintain a software state for each subscribed routing group. For one thing, a client doesn't have access to the timeout parameter of that group, so it could only guess when a server might drop it due to timeout. It could tell by the pinging from a Smart Group, but what about legacy STARnet Groups? In any event, how could the QnetGateway software communicate the subscription status to a radio when the user is subscribed to multiple routing groups? That problem is not easy to solve! Tom N7TAE On 4/15/20 10:57 AM, Elmer Delgado
wrote:
Ahhh but it would help to include something to let you know your logged into the smart groups ?just saying? -- ___________________________ 73 n7tae (at) tearly (dot) net |