Loading ...
Sorry, an error occurred while loading the content.

Re: 2009/08/11 Version Released!

Expand Messages
  • Peter Loveall
    ... This would have been noticed as the server going dumb . If the server s filter is not set properly, then all you will receive is keep-alive comment
    Message 1 of 5 , Aug 11, 2009
    • 0 Attachment
      --- In aprsisce@yahoogroups.com, "ldeffenb" <kj4erj@...> wrote:
      >
      > 5) Corrected the logon string's Version content so we should quit getting the "adjunct HH:MM Missing filter keyword" complaint at login (most of you have probably never noticed anyway).

      This would have been noticed as the server "going dumb". If the server's filter is not set properly, then all you will receive is keep-alive comment lines. I highly recommend that you go back to considering the keep-alive comment lines as confirmation that the server is there and functional.

      If you are concerned about if the login was handled correctly, the logresp comment line that is sent after the login contains confirmation of the login, whether it is verified or not, if the filter was set properly, and what server you logged into.

      The keep-alives are generated after 20 seconds of inactivity on the port -from- the server which is every 20 seconds if you don't set a filter and no one sends you a message. If you do your reads as ReadLine with receivetimeout set to 30000, you shouldn't have any hang issues on reading (be sure to encapsulate in try/catch code looking for any exception). If there is an error, close the connection and try to reconnect.

      73,

      Pete AE5PL
    • ldeffenb
      ... Actually, this would NOT have caused the server dumb. I don t send the filter string with the logon, but send it as a separate command so that I can
      Message 2 of 5 , Aug 11, 2009
      • 0 Attachment
        --- In aprsisce@yahoogroups.com, "Peter Loveall" <pete@...> wrote:
        >
        > --- In aprsisce@yahoogroups.com, "ldeffenb" <kj4erj@> wrote:
        > >
        > > 5) Corrected the logon string's Version content so we should quit getting the "adjunct HH:MM Missing filter keyword" complaint at login (most of you have probably never noticed anyway).
        >
        > This would have been noticed as the server "going dumb". If the server's filter is not set properly, then all you will receive is keep-alive comment lines. I highly recommend that you go back to considering the keep-alive comment lines as confirmation that the server is there and functional.

        Actually, this would NOT have caused the server dumb. I don't send the filter string with the logon, but send it as a separate command so that I can re-send it if the user re-configures the settings. I only put the vers on the logon line, but prior to the fix, my version string had an embedded space causing the server to THINK I was trying to send a filter.

        > If you are concerned about if the login was handled correctly, the logresp comment line that is sent after the login contains confirmation of the login, whether it is verified or not, if the filter was set properly, and what server you logged into.

        I field and log the logresp line to a debug log just for that reason. However, since the filter isn't on the logon line, it doesn't help me with that.

        > The keep-alives are generated after 20 seconds of inactivity on the port -from- the server which is every 20 seconds if you don't set a filter and no one sends you a message. If you do your reads as ReadLine with receivetimeout set to 30000, you shouldn't have any hang issues on reading (be sure to encapsulate in try/catch code looking for any exception). If there is an error, close the connection and try to reconnect.

        My hang issues are with DNS translations and the initial connect as I'm doing the synchronous socket calls currently. I poll the Window Mobile Communications Manager for status, but sometimes even though it APPEARS to be on-line for data, the gethostbyname() and/or connect() calls take a LONG time to timeout.

        I don't issue an recv() call unless an ioctlsocket() shows that there is actually data available for reading, so once I'm connected, hanging is not a problem, just not getting data or an error for an extended time period, what I call the Quiet time limit.

        I WILL re-enable counting the keep-alives as non-quiet traffic as soon as I'm happy that my client is actually working correctly. In the meantime, the 10 or so (max) copies that are out there in use shouldn't be doing much to the APRS-IS.

        73s to you and keep asking the questions, it's how I learned as much as I think I know!

        Lynn (D) - KJ4ERJ
      • Peter Loveall
        ... I would say that since there have been no other reports of javAPRSSrvr just quitting sending packets but maintaining the keep-alives, the server going
        Message 3 of 5 , Aug 11, 2009
        • 0 Attachment
          --- In aprsisce@yahoogroups.com, "ldeffenb" <kj4erj@...> wrote:
          >
          > --- In aprsisce@yahoogroups.com, "Peter Loveall" <pete@> wrote:
          > >
          > > --- In aprsisce@yahoogroups.com, "ldeffenb" <kj4erj@> wrote:
          > > >
          > > > 5) Corrected the logon string's Version content so we should quit getting the "adjunct HH:MM Missing filter keyword" complaint at login (most of you have probably never noticed anyway).
          > >
          > > This would have been noticed as the server "going dumb". If the server's filter is not set properly, then all you will receive is keep-alive comment lines. I highly recommend that you go back to considering the keep-alive comment lines as confirmation that the server is there and functional.
          >
          > Actually, this would NOT have caused the server dumb. I don't send the filter string with the logon, but send it as a separate command so that I can re-send it if the user re-configures the settings. I only put the vers on the logon line, but prior to the fix, my version string had an embedded space causing the server to THINK I was trying to send a filter.

          I would say that since there have been no other reports of javAPRSSrvr just quitting sending packets but maintaining the keep-alives, the server "going dumb" is actually the result of an improper filter setting. The advantage of setting the filter at login is the logresp comment you get back from the server confirming your new filter setting. At any time later, you can still use a comment line to set the filter to something else.

          I am unable to test the software at this point because I have no need for highly active data flows to my cell phone and I want a reconnect attempt as soon as possible when I do use my cell phone for APRS. Personnaly, I find masking a client issue by extending the disconnect time only delays determination of the real cause of a problem and usually leads me to frustration with any software that I work with.

          73,

          Pete AE5PL
        • ldeffenb
          ... I (hopefully) never said it was a server bust. I m dealing with a bunch of unknowns here, and I ve ONLY seen the problem while driving down the road going
          Message 4 of 5 , Aug 11, 2009
          • 0 Attachment
            --- In aprsisce@yahoogroups.com, "Peter Loveall" <pete@...> wrote:
            >
            > I would say that since there have been no other reports of javAPRSSrvr just quitting sending packets but maintaining the keep-alives, the server "going dumb" is actually the result of an improper filter setting. The advantage of setting the filter at login is the logresp comment you get back from the server confirming your new filter setting. At any time later, you can still use a comment line to set the filter to something else.


            I (hopefully) never said it was a server bust. I'm dealing with a bunch of unknowns here, and I've ONLY seen the problem while driving down the road going in and out of cellular coverage. It's not the world's most reproducable environment.

            Since I'm already fielding the #logresp and you've confirmed what I suspected that I'm able to update the filter later no matter which way I specify it, I'll see about embedding the first filter in the logon command.

            >
            > I am unable to test the software at this point because I have no need for highly active data flows to my cell phone and I want a reconnect attempt as soon as possible when I do use my cell phone for APRS. Personnaly, I find masking a client issue by extending the disconnect time only delays determination of the real cause of a problem and usually leads me to frustration with any software that I work with.


            I'm not sure I understand the "reconnect as soon as possible" bit. APRSISCE does try to immediately reconnect if a connection is lost UNLESS the Windows Mobile connection manager status says that it won't succeed anyway. The disconnect time is not delayed, by not counting the keep-alives as traffic, I'm actually ALLOWING the disconnect to occur after the quiet time has expired. Before I started ignoring the keep-alives, the client would simply go (effectively) dead receiving ONLY keepalives until the user got truly frustrated and closed the client.

            I'm not trying to "mask a client issue", I'm trying to resolve the issue while still keeping the Beta functioning at the same time. That's the whole point of BETA software, to work around unknown issues to allow other testing proceed while still attempting to find a permanent resolution to the workarounds. Frustration comes with the Beta landscape and testing partially baked software isn't for everyone.

            I have no doubt that the issue is in my client code, it's certainly the new kid on the well established block. As soon as I understand all of the vagueness of "always on" cellular data connections and the behavior of continuously open sockets across cellular switches, I have every confidence that I'll eliminate the problem. In the meantime, at least the client recovers the connection and gets the feed going again as soon as it notices the lack of non-keep-alive traffic.

            Lynn (D) - KJ4ERJ - Adding my contribution to the APRS community
          Your message has been successfully submitted and would be delivered to recipients shortly.