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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)