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

Reflector bug?

Expand Messages
  • kb9khm
    Robin, I don t know if anyone else had reported this yet, but it seems like there s a bug in the reflector code. It appears that if a stream is in progress on
    Message 1 of 4 , Jul 25, 2008
      Robin,

      I don't know if anyone else had reported this yet, but it seems like
      there's a bug in the reflector code. It appears that if a stream is
      in progress on one module, and another stream starts up on an 2nd
      module, it breaks the stream already in progress on the first module.

      Example:

      1) AB9CD starts a stream on REF001 C
      2) WB2ZY starts a stream on REF001 B
      3) AB9CD's stream breaks (gets cut off in mid transmission)
      4) WB2ZY's stream completes normally

      At the point the steam breaks, the DVTool software always logs:
      "skipping concurrent stream ... "

      The problem appears to be in the reflector code, not DVTool, as
      streams to DPlus also stop. Also, watching TCPDump, the stream of DV
      packets coming from the reflector stops when the issues arises. The
      problem seems to be consistent (reproducible). I've seen it happen
      many times over the last two days.

      Mark (KB9KHM)
    • Robin Cutshaw
      Thanks Mark. I ll take a look... 73, Robin AA4RC ... module. ... DV
      Message 2 of 4 , Jul 26, 2008
        Thanks Mark. I'll take a look...

        73,
        Robin
        AA4RC




        --- In DVDongle@yahoogroups.com, "kb9khm" <kb9khm@...> wrote:
        >
        > Robin,
        >
        > I don't know if anyone else had reported this yet, but it seems like
        > there's a bug in the reflector code. It appears that if a stream is
        > in progress on one module, and another stream starts up on an 2nd
        > module, it breaks the stream already in progress on the first
        module.
        >
        > Example:
        >
        > 1) AB9CD starts a stream on REF001 C
        > 2) WB2ZY starts a stream on REF001 B
        > 3) AB9CD's stream breaks (gets cut off in mid transmission)
        > 4) WB2ZY's stream completes normally
        >
        > At the point the steam breaks, the DVTool software always logs:
        > "skipping concurrent stream ... "
        >
        > The problem appears to be in the reflector code, not DVTool, as
        > streams to DPlus also stop. Also, watching TCPDump, the stream of
        DV
        > packets coming from the reflector stops when the issues arises. The
        > problem seems to be consistent (reproducible). I've seen it happen
        > many times over the last two days.
        >
        > Mark (KB9KHM)
        >
      • Nate Duehr
        ... This was reported by another (UK) ham on Admin some weeks ago with logs from his Gateway connected to REF005. The posting also was the one that triggered
        Message 3 of 4 , Jul 26, 2008
          On Jul 25, 2008, at 9:30 PM, kb9khm wrote:

          > Robin,
          >
          > I don't know if anyone else had reported this yet, but it seems like
          > there's a bug in the reflector code. It appears that if a stream is
          > in progress on one module, and another stream starts up on an 2nd
          > module, it breaks the stream already in progress on the first module.


          This was reported by another (UK) ham on Admin some weeks ago with
          logs from his Gateway connected to REF005. The posting also was the
          one that triggered the admins of Admin to start moderating posts there.

          Personally, I've spent a number of commutes talking on REF001C and
          folks there have taken to calling the number of things that can make
          transmissions just "disappear" the "Reflector black hole". I wouldn't
          recommend Reflector links for real emergency or critical
          communications at this point in time, but I doubt Robin would either?
          Due to the nature of digital, they just don't "act the same" as other
          linking technologies yet.

          (At least in callsign routing/multicast, the user gets some feedback
          on their display as to whether or not they routed and were heard...
          "RPT" vs. "UR". I've been talking on Reflectors on D-STAR for a while
          now, and it's really common for a whole transmission to just disappear
          in a normal QSO. While I know in my head what's happening is
          doubling, radios spitting out GPS data beacons, etc... and there are
          good technical reasons why this happens, I can't get used to it...
          having someone call you and say "Are you still there?" every five to
          seven overs, is getting kinda annoying.)

          Doubling is not handled well either... not sure it can be, thinking
          over what's really happening... but perhaps a very smart Reflector
          would buffer both transmissions, and/or generate a header and fake a
          new transmission that's actually a remainder of the longest
          transmission's stream, if two people double.

          But it's not there yet... It's very hard to tell when someone
          doubles or this "both sub-channels are in use" thing happens.

          There also seems to be anecdotal evidence that the connection and
          disconnection of Dongles to outlying Gateways connected to a Reflector
          can interrupt on-going communications also, but no one seems to care
          enough to try to test it to find the reproducible cases that break it.

          We're all just getting used to saying "Say again? Did you get my
          transmission?", and that's probably not good... boiling a frog works
          if the water temperature is raised slowly enough.

          NOT complaining about Robin's code... just saying there's not much
          anyone else can do about it. Robin already mentioned that some wack-
          job convinced him not to open-source the Reflector code because of
          concern that "terrorists" might read it in his Dayton presentation...
          so I doubt that's going to change. (Emotion trumps reality... there
          are plenty of other ways to break the entire D-STAR network without
          resorting to reading Robin's Reflector source code.)

          --
          Nate Duehr, WY0X
          nate@...
        • Tony Langdon
          ... I had noticed odd things like that seemed to happen when on the SE WX net. Couldn t work out what was going on, but this thread seems to be shedding some
          Message 4 of 4 , Jul 27, 2008
            At 07:48 AM 7/27/2008, you wrote:

            >Personally, I've spent a number of commutes talking on REF001C and
            >folks there have taken to calling the number of things that can make
            >transmissions just "disappear" the "Reflector black hole". I wouldn't
            >recommend Reflector links for real emergency or critical

            I had noticed odd things like that seemed to happen when on the SE WX
            net. Couldn't work out what was going on, but this thread seems to
            be shedding some light on the situation

            >communications at this point in time, but I doubt Robin would either?
            >Due to the nature of digital, they just don't "act the same" as other
            >linking technologies yet.

            Well, all of our Internet based options are digital at the reflector. :-)

            >(At least in callsign routing/multicast, the user gets some feedback
            >on their display as to whether or not they routed and were heard...

            Maybe, if one is able to look at the display quick enough - often the
            repeater ID trashes the more useful response from the remote gateway.

            >"RPT" vs. "UR". I've been talking on Reflectors on D-STAR for a while
            >now, and it's really common for a whole transmission to just disappear
            >in a normal QSO. While I know in my head what's happening is

            I've heard that too, though sometimes other stations hear it, and I
            don't on the Dongle.

            >doubling, radios spitting out GPS data beacons, etc... and there are
            >good technical reasons why this happens, I can't get used to it...
            >having someone call you and say "Are you still there?" every five to
            >seven overs, is getting kinda annoying.)

            I haven't done much ragchewing on reflectors, mostly controlled nets,
            so I haven't had to deal with that so much at this stage. That would
            be a bit annoying, though I get that a lot on IRLP and Echolink as
            well, so I'd probably notice it less anyway. The reasons on IRLP and
            Echolink range from someone doubling, to rubber ears, to accent
            problems, or simply the other fool deciding to wander away from their
            PC or radio! As I don't expect D-STAR users to be that much
            different, I would expect the same strike rate. ;)


            >Doubling is not handled well either... not sure it can be, thinking
            >over what's really happening... but perhaps a very smart Reflector
            >would buffer both transmissions, and/or generate a header and fake a
            >new transmission that's actually a remainder of the longest
            >transmission's stream, if two people double.

            Or perhaps it just needs to buffer the header and slap it on at the
            start of the remainder of the longer transmission?


            >But it's not there yet... It's very hard to tell when someone
            >doubles or this "both sub-channels are in use" thing happens.

            The subchannel thing sounds weird.

            >NOT complaining about Robin's code... just saying there's not much
            >anyone else can do about it. Robin already mentioned that some wack-
            >job convinced him not to open-source the Reflector code because of
            >concern that "terrorists" might read it in his Dayton presentation...
            >so I doubt that's going to change. (Emotion trumps reality... there
            >are plenty of other ways to break the entire D-STAR network without
            >resorting to reading Robin's Reflector source code.)

            Well, this raises the counter argument that maybe the risk of
            terrorists reading Robin's code and doing something nasty with it is
            less than the potential benefits of having more "friend;y eyes" looking at it?

            The AllStar guys obviously aren't too worried about this issue
            (Asterisk, which AllStar uses, is open source), not to mention the
            various organisations that use Asterisk for their telephony needs.

            73 de VK3JED
            http://vkradio.com
          Your message has been successfully submitted and would be delivered to recipients shortly.