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

feature requests

Expand Messages
  • PE1RDW
    Hello John and everyone else I have some feature requests that might help with troughput on higher speed links and enhance eachother First is extended ax25 or
    Message 1 of 7 , Dec 22, 2012
    • 0 Attachment
      Hello John and everyone else

      I have some feature requests that might help with troughput on higher
      speed links and enhance eachother

      First is extended ax25 or modulo 128 support, this will allow windows up
      to 128 frames

      Second is framesamler, first introduced on flexnet, and currently also
      suported on uz7ho, keep the good recieved frames even if one frame is
      missing in between so you can proceed after the last frame once the
      missing frame is recieved.

      And finaly selective reject support, it might already be supported and
      missed by me but it goes along with the framesamler, when a reject is
      recieved only transmit that frame, the opposing station will then skip the
      frames it did already recieve and either send a rr for the last good
      recieved frame or another reject if there are more missing frames between,
      if the opposing station does not have a frame sampler it will just send a
      rr for the frame after the reject responce so either way you can pick up
      as normal after the rr

      One word of warning about the framesamler, if the opposing station has a
      window of 7 for normal ax25 or 128 for extended ax25 there is a change of
      data loss so might want to check for that condition.

      ps. happy hollidays and good new year
      --
      73 Andre PE1RDW
    • PE1RDW
      ... I did a bit more looking for supporting documentation Original implementation document in net http://pe1chl.xs4all.nl/NET/extseq.lzh XR32 manual page 34
      Message 2 of 7 , Dec 26, 2012
      • 0 Attachment
        On Sat, 22 Dec 2012 15:05:39 +0100, PE1RDW <pe1rdw@...> wrote:

        >
        > Hello John and everyone else
        >
        > I have some feature requests that might help with troughput on higher
        > speed links and enhance eachother
        >
        > First is extended ax25 or modulo 128 support, this will allow windows up
        > to 128 frames
        >
        > Second is framesamler, first introduced on flexnet, and currently also
        > suported on uz7ho, keep the good recieved frames even if one frame is
        > missing in between so you can proceed after the last frame once the
        > missing frame is recieved.
        >
        > And finaly selective reject support, it might already be supported and
        > missed by me but it goes along with the framesamler, when a reject is
        > recieved only transmit that frame, the opposing station will then skip
        > the
        > frames it did already recieve and either send a rr for the last good
        > recieved frame or another reject if there are more missing frames
        > between,
        > if the opposing station does not have a frame sampler it will just send a
        > rr for the frame after the reject responce so either way you can pick up
        > as normal after the rr
        >
        > One word of warning about the framesamler, if the opposing station has a
        > window of 7 for normal ax25 or 128 for extended ax25 there is a change of
        > data loss so might want to check for that condition.
        >
        > ps. happy hollidays and good new year

        I did a bit more looking for supporting documentation
        Original implementation document in net
        http://pe1chl.xs4all.nl/NET/extseq.lzh
        XR32 manual page 34 has some info as wel
        http://vk2dot.dyndns.org/XR32/XR32.pdf
        and a discussion on the topic in a tcp mailing list
        http://www.a00.de/tcpgroup/1995/msg00176.php

        --
        73 Andre PE1RDW
      • John Wiseman
        Thanks, Andre. I did once have code to save out of sequence frames, but could never get it to work reliably, so disabled it. I am currently rewriting my ax.25
        Message 3 of 7 , Dec 26, 2012
        • 0 Attachment
          Thanks, Andre.

          I did once have code to save out of sequence frames, but could never get it
          to work reliably, so disabled it. I am currently rewriting my ax.25 code in
          'c' so it can be ported to linux, and have reintroduced the code, though it
          is still not fully tested.

          With the old code modulo 128 would have been difficult, though it should be
          easier with the 'C' version. With both this and SREJ, I have been concerned
          with maintaining backward compatibility. I'll probably look into both once I
          have the new code fully stable.

          73,
          John


          -----Original Message-----
          From: BPQ32@yahoogroups.com [mailto:BPQ32@yahoogroups.com] On Behalf Of
          PE1RDW
          Sent: 26 December 2012 13:19
          To: BPQ32@yahoogroups.com
          Subject: Re: [BPQ32] feature requests

          On Sat, 22 Dec 2012 15:05:39 +0100, PE1RDW <pe1rdw@...> wrote:

          >
          > Hello John and everyone else
          >
          > I have some feature requests that might help with troughput on higher
          > speed links and enhance eachother
          >
          > First is extended ax25 or modulo 128 support, this will allow windows
          > up to 128 frames
          >
          > Second is framesamler, first introduced on flexnet, and currently also
          > suported on uz7ho, keep the good recieved frames even if one frame is
          > missing in between so you can proceed after the last frame once the
          > missing frame is recieved.
          >
          > And finaly selective reject support, it might already be supported and
          > missed by me but it goes along with the framesamler, when a reject is
          > recieved only transmit that frame, the opposing station will then skip
          > the frames it did already recieve and either send a rr for the last
          > good recieved frame or another reject if there are more missing frames
          > between, if the opposing station does not have a frame sampler it will
          > just send a rr for the frame after the reject responce so either way
          > you can pick up as normal after the rr
          >
          > One word of warning about the framesamler, if the opposing station has
          > a window of 7 for normal ax25 or 128 for extended ax25 there is a
          > change of data loss so might want to check for that condition.
          >
          > ps. happy hollidays and good new year

          I did a bit more looking for supporting documentation Original
          implementation document in net http://pe1chl.xs4all.nl/NET/extseq.lzh
          XR32 manual page 34 has some info as wel
          http://vk2dot.dyndns.org/XR32/XR32.pdf
          and a discussion on the topic in a tcp mailing list
          http://www.a00.de/tcpgroup/1995/msg00176.php

          --
          73 Andre PE1RDW


          ------------------------------------

          Yahoo! Groups Links
        • PE1RDW
          Good to hear there is so much progress, offcourse for your linux version you probably won t need a ax25 stack because you can just use the one in the kernel,
          Message 4 of 7 , Dec 26, 2012
          • 0 Attachment
            Good to hear there is so much progress, offcourse for your linux version
            you probably won't need a ax25 stack because you can just use the one in
            the kernel, although that code has not been touched in years and is from
            what I been told rather sloppy, I have done eax25 with linux before and
            was impressed with how wel it preformed.

            Advantage of using your own code is that you will have a lot better
            controll over timing and can do tricks the kernel can not do like adoptive
            timing but usualy the gain of that is limited especialy in today's
            channels that are a lot less congested then they where in the 90's

            --
            73 Andre PE1RDW
            On Wed, 26 Dec 2012 14:30:03 +0100, John Wiseman <john.wiseman@...>
            wrote:

            > Thanks, Andre.
            >
            > I did once have code to save out of sequence frames, but could never get
            > it
            > to work reliably, so disabled it. I am currently rewriting my ax.25 code
            > in
            > 'c' so it can be ported to linux, and have reintroduced the code, though
            > it
            > is still not fully tested.
            >
            > With the old code modulo 128 would have been difficult, though it should
            > be
            > easier with the 'C' version. With both this and SREJ, I have been
            > concerned
            > with maintaining backward compatibility. I'll probably look into both
            > once I
            > have the new code fully stable.
            >
            > 73,
            > John
            >
            > -----Original Message-----
            > From: BPQ32@yahoogroups.com [mailto:BPQ32@yahoogroups.com] On Behalf Of
            > PE1RDW
            > Sent: 26 December 2012 13:19
            > To: BPQ32@yahoogroups.com
            > Subject: Re: [BPQ32] feature requests
            >
            > On Sat, 22 Dec 2012 15:05:39 +0100, PE1RDW <pe1rdw@...> wrote:
            >
            >>
            >> Hello John and everyone else
            >>
            >> I have some feature requests that might help with troughput on higher
            >> speed links and enhance eachother
            >>
            >> First is extended ax25 or modulo 128 support, this will allow windows
            >> up to 128 frames
            >>
            >> Second is framesamler, first introduced on flexnet, and currently also
            >> suported on uz7ho, keep the good recieved frames even if one frame is
            >> missing in between so you can proceed after the last frame once the
            >> missing frame is recieved.
            >>
            >> And finaly selective reject support, it might already be supported and
            >> missed by me but it goes along with the framesamler, when a reject is
            >> recieved only transmit that frame, the opposing station will then skip
            >> the frames it did already recieve and either send a rr for the last
            >> good recieved frame or another reject if there are more missing frames
            >> between, if the opposing station does not have a frame sampler it will
            >> just send a rr for the frame after the reject responce so either way
            >> you can pick up as normal after the rr
            >>
            >> One word of warning about the framesamler, if the opposing station has
            >> a window of 7 for normal ax25 or 128 for extended ax25 there is a
            >> change of data loss so might want to check for that condition.
            >>
            >> ps. happy hollidays and good new year
            >
            > I did a bit more looking for supporting documentation Original
            > implementation document in net http://pe1chl.xs4all.nl/NET/extseq.lzh
            > XR32 manual page 34 has some info as wel
            > http://vk2dot.dyndns.org/XR32/XR32.pdf
            > and a discussion on the topic in a tcp mailing list
            > http://www.a00.de/tcpgroup/1995/msg00176.php
            >
            > --
            > 73 Andre PE1RDW
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >
          • John Wiseman
            Andre, I was originally going to use the kernel ax.25 stack, but found it needed a unique call for each interface, which is pretty restrictive if you want a
            Message 5 of 7 , Dec 26, 2012
            • 0 Attachment
              Andre,

              I was originally going to use the kernel ax.25 stack, but found it needed a
              unique call for each interface, which is pretty restrictive if you want a
              multiport node. So I decided to use my own code.

              73, John


              -----Original Message-----
              From: BPQ32@yahoogroups.com [mailto:BPQ32@yahoogroups.com] On Behalf Of
              PE1RDW
              Sent: 26 December 2012 22:00
              To: BPQ32@yahoogroups.com
              Subject: Re: [BPQ32] feature requests

              Good to hear there is so much progress, offcourse for your linux version you
              probably won't need a ax25 stack because you can just use the one in the
              kernel, although that code has not been touched in years and is from what I
              been told rather sloppy, I have done eax25 with linux before and was
              impressed with how wel it preformed.

              Advantage of using your own code is that you will have a lot better controll
              over timing and can do tricks the kernel can not do like adoptive timing but
              usualy the gain of that is limited especialy in today's channels that are a
              lot less congested then they where in the 90's

              --
              73 Andre PE1RDW
              On Wed, 26 Dec 2012 14:30:03 +0100, John Wiseman <john.wiseman@...>
              wrote:

              > Thanks, Andre.
              >
              > I did once have code to save out of sequence frames, but could never
              > get it to work reliably, so disabled it. I am currently rewriting my
              > ax.25 code in 'c' so it can be ported to linux, and have reintroduced
              > the code, though it is still not fully tested.
              >
              > With the old code modulo 128 would have been difficult, though it
              > should be easier with the 'C' version. With both this and SREJ, I have
              > been concerned with maintaining backward compatibility. I'll probably
              > look into both once I have the new code fully stable.
              >
              > 73,
              > John
              >
              > -----Original Message-----
              > From: BPQ32@yahoogroups.com [mailto:BPQ32@yahoogroups.com] On Behalf
              > Of PE1RDW
              > Sent: 26 December 2012 13:19
              > To: BPQ32@yahoogroups.com
              > Subject: Re: [BPQ32] feature requests
              >
              > On Sat, 22 Dec 2012 15:05:39 +0100, PE1RDW <pe1rdw@...> wrote:
              >
              >>
              >> Hello John and everyone else
              >>
              >> I have some feature requests that might help with troughput on higher
              >> speed links and enhance eachother
              >>
              >> First is extended ax25 or modulo 128 support, this will allow windows
              >> up to 128 frames
              >>
              >> Second is framesamler, first introduced on flexnet, and currently
              >> also suported on uz7ho, keep the good recieved frames even if one
              >> frame is missing in between so you can proceed after the last frame
              >> once the missing frame is recieved.
              >>
              >> And finaly selective reject support, it might already be supported
              >> and missed by me but it goes along with the framesamler, when a
              >> reject is recieved only transmit that frame, the opposing station
              >> will then skip the frames it did already recieve and either send a rr
              >> for the last good recieved frame or another reject if there are more
              >> missing frames between, if the opposing station does not have a frame
              >> sampler it will just send a rr for the frame after the reject
              >> responce so either way you can pick up as normal after the rr
              >>
              >> One word of warning about the framesamler, if the opposing station
              >> has a window of 7 for normal ax25 or 128 for extended ax25 there is a
              >> change of data loss so might want to check for that condition.
              >>
              >> ps. happy hollidays and good new year
              >
              > I did a bit more looking for supporting documentation Original
              > implementation document in net http://pe1chl.xs4all.nl/NET/extseq.lzh
              > XR32 manual page 34 has some info as wel
              > http://vk2dot.dyndns.org/XR32/XR32.pdf
              > and a discussion on the topic in a tcp mailing list
              > http://www.a00.de/tcpgroup/1995/msg00176.php
              >
              > --
              > 73 Andre PE1RDW
              >
              >
              > ------------------------------------
              >
              > Yahoo! Groups Links
              >
              >
              >
              >
              >
              > ------------------------------------
              >
              > Yahoo! Groups Links
              >
              >
              >


              ------------------------------------

              Yahoo! Groups Links
            • PE1RDW
              Ah yes, almost forgot about that litle restriction. It comes from a limitation in the tcp/ip stack, every interface needs to have it s own mac adress and for
              Message 6 of 7 , Dec 26, 2012
              • 0 Attachment
                Ah yes, almost forgot about that litle restriction.
                It comes from a limitation in the tcp/ip stack, every interface needs to
                have it's own mac adress and for ax25 this is the interface call.
                Luckely applications can still assign their own calls so you can work
                around it but it remains a kludge.

                And it is always better for portability to have your own stack so you
                don't need to maintain different code for linux and windows.

                And it is very easy under linux to tunnel other ax25 stacks trough the
                kernel ax25 stack with net2kiss so people can still use it if they want.

                --
                73 Andre PE1RDW

                On Wed, 26 Dec 2012 23:08:22 +0100, John Wiseman <john.wiseman@...>
                wrote:

                > Andre,
                >
                > I was originally going to use the kernel ax.25 stack, but found it
                > needed a
                > unique call for each interface, which is pretty restrictive if you want a
                > multiport node. So I decided to use my own code.
                >
                > 73, John
                >
                > -----Original Message-----
                > From: BPQ32@yahoogroups.com [mailto:BPQ32@yahoogroups.com] On Behalf Of
                > PE1RDW
                > Sent: 26 December 2012 22:00
                > To: BPQ32@yahoogroups.com
                > Subject: Re: [BPQ32] feature requests
                >
                > Good to hear there is so much progress, offcourse for your linux version
                > you
                > probably won't need a ax25 stack because you can just use the one in the
                > kernel, although that code has not been touched in years and is from
                > what I
                > been told rather sloppy, I have done eax25 with linux before and was
                > impressed with how wel it preformed.
                >
                > Advantage of using your own code is that you will have a lot better
                > controll
                > over timing and can do tricks the kernel can not do like adoptive timing
                > but
                > usualy the gain of that is limited especialy in today's channels that
                > are a
                > lot less congested then they where in the 90's
                >
                > --
                > 73 Andre PE1RDW
              • Charles Brabham
                I wonder if this has anything to do with the FlexNet folks sticking with DOS and Windows, some years back. A Linux version was often requested, and once
                Message 7 of 7 , Dec 26, 2012
                • 0 Attachment
                  I wonder if this has anything to do with the FlexNet folks sticking with
                  DOS and Windows, some years back. A Linux version was often requested,
                  and once considered, but in the end no Linux version was ever offered.

                  73 DE Charles, N5PVL


                  On 12/26/2012 4:36 PM, PE1RDW wrote:
                  > Ah yes, almost forgot about that litle restriction.
                  > It comes from a limitation in the tcp/ip stack, every interface needs to
                  > have it's own mac adress and for ax25 this is the interface call.
                  > Luckely applications can still assign their own calls so you can work
                  > around it but it remains a kludge.
                  >
                  > And it is always better for portability to have your own stack so you
                  > don't need to maintain different code for linux and windows.
                  >
                  > And it is very easy under linux to tunnel other ax25 stacks trough the
                  > kernel ax25 stack with net2kiss so people can still use it if they want.
                  >
                Your message has been successfully submitted and would be delivered to recipients shortly.