• SyncTerm Question...

    From Ozz Nixon@21:1/144 to All on Fri Jul 5 23:45:32 2019
    Reading an XModem Variant specs, does SyncTerm support #2,3, or 4?

    1. Standard XMODEM with 128 byte per block and 16-Bit CRC.
    2. Extended XMODEM with receiver requesting 32K byte per block.
    3. Extended XMODEM with receiver requesting 64K byte per block.
    4. Extended XMODEM with receiver requesting 8K byte per block.

    ??? If yes, any special header I should send on XModem to let it know I
    am about to dump 8k or more instead of 128b?

    Thanks!
    Ozz

    --- ExchangeBBS NNTP Server v3.1/Linux64
    * Origin: nntp://bbs.exchangebbs.com:119/ (21:1/144.0)
  • From Avon@21:1/101 to Ozz Nixon on Sat Jul 6 15:24:10 2019
    On 05 Jul 2019 at 11:45p, Ozz Nixon pondered and said...

    Reading an XModem Variant specs, does SyncTerm support #2,3, or 4?

    I'm sure Digital Man will come back to you on this one Ozz :)

    But seeing you're here just a quick Hi from me and hope all the coding and
    work on your BBS is going well. You're always busy, well that's what it looks like from way over here :)

    Best, Paul

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Ozz Nixon@21:1/144 to Avon on Sun Jul 7 02:05:36 2019
    On 2019-07-06 15:24:10 +0000, Avon -> Ozz Nixon said:

    On 05 Jul 2019 at 11:45p, Ozz Nixon pondered and said...

    Reading an XModem Variant specs, does SyncTerm support #2,3, or 4?

    I'm sure Digital Man will come back to you on this one Ozz :)

    Hope so... would like to make sure all the efforts I am doing full take advantage of SyncTerm - fonts, graphics and sound (if it does it), and
    faster protocols.


    But seeing you're here just a quick Hi from me and hope all the coding and work on your BBS is going well. You're always busy, well that's what it
    looks
    like from way over here :)

    Yes, the Alpha test we just did this week was a success, I have
    squashed all but 1 reported bug... then we focus more of XFer, and MRC
    chat. I hope to wrap them up next week... then wrap back around and do
    a security level test end to end ... if all goes well, August release
    date will be are next focus ;-)

    Cheers!
    Ozz aka SqZ

    --- ExchangeBBS NNTP Server v3.1/Linux64
    * Origin: nntp://bbs.exchangebbs.com:119/ (21:1/144.0)
  • From Spectre@21:3/105 to Ozz Nixon on Mon Jul 8 02:38:00 2019
    Reading an XModem Variant specs, does SyncTerm support #2,3, or 4?

    ??? If yes, any special header I should send on XModem to let it know I
    am about to dump 8k or more instead of 128b?

    Isn't X-Modem 8k really Y-modem? Or was that 1k.. been a while, but there was some cross over between the two...

    Spectre


    *** THE READER V4.50 [freeware]

    ---
    * Origin: Default origin line (21:3/105)
  • From Avon@21:1/101 to Ozz Nixon on Mon Jul 8 12:17:12 2019
    On 07 Jul 2019 at 02:05a, Ozz Nixon pondered and said...

    Yes, the Alpha test we just did this week was a success, I have
    squashed all but 1 reported bug... then we focus more of XFer, and MRC chat. I hope to wrap them up next week... then wrap back around and do
    a security level test end to end ... if all goes well, August release date will be are next focus ;-)

    Sounds good.. how do you plan to distribute it, and where do folks
    find out more re testing opportunities?

    --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Digital Man@21:1/183 to Ozz Nixon on Sun Jul 7 21:40:26 2019
    Re: SyncTerm Question...
    By: Ozz Nixon to All on Fri Jul 05 2019 11:45 pm

    Reading an XModem Variant specs, does SyncTerm support #2,3, or 4?

    1. Standard XMODEM with 128 byte per block and 16-Bit CRC.
    2. Extended XMODEM with receiver requesting 32K byte per block.
    3. Extended XMODEM with receiver requesting 64K byte per block.
    4. Extended XMODEM with receiver requesting 8K byte per block.

    No.

    ??? If yes, any special header I should send on XModem to let it know I
    am about to dump 8k or more instead of 128b?

    Firstly, XMODEM is a pretty bad protocol (no file name/metadata, up to 127 bytes of garbage tacked on received files, no streaming). If you're going to work on extending any legacy protocols, I would start with YMODEM at minimum.

    digital man

    This Is Spinal Tap quote #22:
    David St. Hubbins: Here lies David St. Hubbins... and why not?
    Norco, CA WX: 62.2øF, 85.0% humidity, 1 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.07-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)
  • From Ozz Nixon@21:1/144 to Digital Man on Mon Jul 8 18:03:32 2019
    On 2019-07-07 21:40:27 +0000, Digital Man -> Ozz Nixon said:
    Firstly, XMODEM is a pretty bad protocol (no file name/metadata, up to 127 bytes of garbage tacked on received files, no streaming). If you're going to work on extending any legacy protocols, I would start with YMODEM at
    minimum.

    I am all for it... their XModem extensions apply to both X and Y. Does SyncTerm YModem support more than 1K? I am keen on publishing protocols
    like -G or Windowed, so it is push w/o epecting error(s).

    I did a simple terminal, and pushed 480Kbs up to the server... which
    was 100% saturation of my outbound at the house (I know SLOW).

    The protocol is VERY simple (like Modem7 & YModem - with a few header
    changes):

    Like BinkP CRC mode = $80000000 means start at -1 (wait for client to
    send 0, or resume point)

    Data_Len_Byte = Value * 1024 = Block Size, acceptable values 1, 2, 4, 8, 16,
    32

    EXAMPLE:
    ========
    C: Sender Wait for Ctrl-E (Enquiry) up to 30 seconds, timeout=return to BBS
    S: STX + null terminated filename + EPOCH 64bit (ASCII, ZERO PAD LEFT)
    + FileSize (ASCII) + CRC16 + Data_Len_Byte + $80000000 ETX (as we
    expect no errors on TCP most of the time, Data_Len_Byte and $80000000
    and ETX are not part of CRC16)
    C: $00000000 (denotes start sending at 0th byte, could be any value up
    to $7FFFFFFF)
    (*) If timestamp has changed, client will always send $00000000
    (*) If partial exists, timestamp matches, send FileSize(handle) in HEX
    [8 characters]
    (**) Where $00000001 = start at byte 1, and $10000000 = start at byte 268,435,456 and $7FFFFFFF is the maximum RESUME pos (2,147,483,647 -
    sorry if you needed to resume at 5gb - this will always resume at
    2.1gb).
    S: SOH + Block# + ~Block# + DATA0 ... DATAn CRC_HI CRC_LO
    S: SOH + Block# + ~Block# + DATA0 ... DATAn CRC_HI CRC_LO
    S: SOH + Block# + ~Block# + DATA0 ... DATAn CRC_HI CRC_LO
    {...}
    S: SOH + Block# + ~Block# + DATA0 ... DATAn CRC_HI CRC_LO + EOT
    Return to BBS Success.

    1. When a Side is waiting for a reply, timeout is 1000ms (1 second,
    18.2 ticks) - timeout = fatal (cancel xfer)
    2. We do not scale up and down, Data_Len_Byte applies from first to
    next to last block, where last block can be anywhere from 1 to
    Data_Len_Byte in length.
    3. When resuming xfer or starting from 0 - First Block# is 1 - do not
    try to calculate last block received on a resume, as it could be a
    partial if resuming at a different Data_Len_Byte size - which is
    acceptable.

    I am still testing this - going to put the script on 2 servers with
    10gig fiber between them and see how fast can I push this - and would
    it make send to have packets larger than 32kb + 5b.

    Ozz

    --- ExchangeBBS NNTP Server v3.1/Linux64
    * Origin: nntp://bbs.exchangebbs.com:119/ (21:1/144.0)
  • From Ozz Nixon@21:1/144 to Avon on Mon Jul 8 18:12:32 2019
    On 2019-07-08 12:17:12 +0000, Avon -> Ozz Nixon said:

    On 07 Jul 2019 at 02:05a, Ozz Nixon pondered and said...

    Yes, the Alpha test we just did this week was a success, I have
    squashed all but 1 reported bug... then we focus more of XFer, and MRC chat. I hope to wrap them up next week... then wrap back around and do
    a security level test end to end ... if all goes well, August release date will be are next focus ;-)

    Sounds good.. how do you plan to distribute it, and where do folks
    find out more re testing opportunities?

    I am planning on Hatching via:
    Araknet
    Fidonet
    FSXNet (of course)
    Github
    SaltairBBS
    ExchangeBBS
    May actually do a UUencode and release on Usenet and in echos too.

    I will probably only release the source - people will have to go to
    either ModernPascal.com or Github.com to get Coderunner to bring the
    system up on the supported OSes. The only binary release will be for DOS/16bit.

    Then I have to decide will we focus on PCB 16.1 or QuickBBS 3.0 - or
    Unveil ExchangeBBS with PNG Graphics (totally different feel - especial
    in the gameroom). ;-)

    Ozz aka SqZ




    --- ExchangeBBS NNTP Server v3.1/Linux64
    * Origin: nntp://bbs.exchangebbs.com:119/ (21:1/144.0)
  • From Digital Man@21:1/183 to Ozz Nixon on Mon Jul 8 20:16:40 2019
    Re: Re: SyncTerm Question...
    By: Ozz Nixon to Digital Man on Mon Jul 08 2019 06:03 pm

    On 2019-07-07 21:40:27 +0000, Digital Man -> Ozz Nixon said:
    Firstly, XMODEM is a pretty bad protocol (no file name/metadata, up to 127 bytes of garbage tacked on received files, no streaming). If you're going to work on extending any legacy protocols, I would start with YMODEM at
    minimum.

    I am all for it... their XModem extensions apply to both X and Y. Does SyncTerm YModem support more than 1K?

    No. I've never seen a spec on any version of YMODEM that sends more than 1K blocks. There's only 2 X/YMODEM start-of-block chars I'm aware of:

    SOH: 128-byte block
    STX: 1024-byte block

    You know of others?

    digital man

    This Is Spinal Tap quote #16:
    David St. Hubbins: I believe virtually everything I read...
    Norco, CA WX: 67.4øF, 72.0% humidity, 11 mph E wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.07-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)
  • From Ozz Nixon@21:1/144 to Digital Man on Tue Jul 9 09:59:18 2019
    On 2019-07-08 20:16:41 +0000, Digital Man -> Ozz Nixon said:

    No. I've never seen a spec on any version of YMODEM that sends more than 1K blocks. There's only 2 X/YMODEM start-of-block chars I'm aware of:

    SOH: 128-byte block
    STX: 1024-byte block

    You know of others?

    https://www.adontec.com/Extended_XMODEM.pdf

    Block Size Options:

    XM_32K_CHAR '0' 32768 bytes per block
    XM_64K_CHAR '1' 65536 bytes per block
    XM_8K_CHAR '2' 8192 bytes per block
    etc.

    e.g. DLE '0' 'C'in order to request block size of 32K.

    --- ExchangeBBS NNTP Server v3.1/Linux64
    * Origin: nntp://bbs.exchangebbs.com:119/ (21:1/144.0)
  • From Digital Man@21:1/183 to Ozz Nixon on Tue Jul 9 14:58:20 2019
    Re: Re: SyncTerm Question...
    By: Ozz Nixon to Digital Man on Tue Jul 09 2019 09:59 am

    On 2019-07-08 20:16:41 +0000, Digital Man -> Ozz Nixon said:

    No. I've never seen a spec on any version of YMODEM that sends more than 1K blocks. There's only 2 X/YMODEM start-of-block chars I'm aware of:

    SOH: 128-byte block
    STX: 1024-byte block

    You know of others?

    https://www.adontec.com/Extended_XMODEM.pdf

    Looks like they successfully redefined YMODEM (with their "/FI" definition). Ugh.

    Block Size Options:

    XM_32K_CHAR '0' 32768 bytes per block
    XM_64K_CHAR '1' 65536 bytes per block
    XM_8K_CHAR '2' 8192 bytes per block
    etc.

    e.g. DLE '0' 'C'in order to request block size of 32K.

    Without their "/FI" extension, you end up with ~32Kbytes of additional data on all your received files. Nobody wants that.

    I would think if you wanted to extend something, start with YMODEM, not XMODEM.
    Oh wait, I already said that I think. :-)

    digital man

    This Is Spinal Tap quote #21:
    So when you're playing you feel like a preserved moose on stage?
    Norco, CA WX: 86.4øF, 39.0% humidity, 11 mph ENE wind, 0.00 inches rain/24hrs --- SBBSecho 3.07-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)