exec/load binkp.js 1.122 1.123
Update of /cvsroot/sbbs/exec/load
In directory cvs:/tmp/cvs-serv22684

Modified Files:
binkp.js
Log Message:
When a file fails to open, log the error value, e.g. this:
Error 24 opening '../fido/outbound/5e7a2520.pkt'. Not sending.
instead of this:
Unable to open '../fido/outbound/5e7ab832.pkt'. Not sending.

Error 24 is "too many open files", btw. Another problem to solve.


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/d1566e7d7b3a9e013f244cea
Modified Files:
exec/load/binkp.js
Log Message:
Don't assume the BinkP VER message contains 3-space-delimited fields.

According to both FTS-1026 and FSP-1024, the "mailer version" portion of this msg may contain spaces. Some mailers (e.g. Internet Rex), provide their version information with spaces, e.g. "Internet Rex 2.67 beta 1a OS/2 (binkp/1.1)", which also include a non-conformant protocol version indicator:
" (binkp/1.1)" instead of " binkp/1.1".
Additionally, only require that "binkp/" exist in the string, to find and
parse the protocol version number, which is apparently critical to the proper operation of the protocol. This should resolve issue #185 reported by altere.

I'm also storing the entire VER response in the binkp.remote_ver property and this will break the older Mystic/BinkP work-arounds in binkit.js. I dont' think we really need those workarounds any longer however. We'll soon see I guess.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/b846192f8b436fac248fd9d9
Modified Files:
exec/load/binkp.js
Log Message:
Just parse VER using /^VER (.*) ([^ ]*?)$/

This restores the meaning of remote_ver and still has a hack for
broken, unfixable mailers that don't advertise protocol v1.1
correctly (ie: Irex)

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/6b6a6f506c94d2ae98735741
Modified Files:
exec/load/binkp.js
Log Message:
Log warning when peer does not indicate binkp/1.1 correctly, but
we assume it's 1.1 anyway.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/aba949fa751a58c9e781372d
Modified Files:
exec/load/binkp.js
Log Message:
Add comment containing what Internet Rex sends.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/d218c8de9ff3cd359f101409
Modified Files:
exec/load/binkp.js
Log Message:
"Handle" frames with a data length of zero.

These frames were already not allowed in the binkp/1.0 protocol,
and it is mentioned in the spec (issued in 2005) as "Some old
implementations do send empty frames as the last frame.".

It's certainly not allowed now, and any mailer which does it is
broken.

For zero-length data packets, it will be seen as a frame containing
zero data bytes which will also be logged as being after the file
if it comes after the file has already been completely transferred.

A zero-length command packet will abort with M_ERR, logging an error
regarding command number NaN or something like that.

This may fix #185 since attempting a recv() of zero bytes and
succeeding is the only way I can see for a zero second timeout to
have been logged in receving frame data. The software assumed that
receiving zero bytes was a timeout, but if that's what you asked for,
it's actually success.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/f6cc52385b146eb2def3ad21
Modified Files:
exec/load/binkp.js
Log Message:
Apparently we're editing file revisions like cavemen now.

Call this one "2"
Flashbacks to manually editing zone files here.
I may end up going with YYYYMMDD numbers like I sometimes did in
zone files, but maybe I'll just do the single number thing... not
really sure yet.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/a0b4a7cf8e4e1b79e75805ed
Modified Files:
exec/load/binkp.js
Log Message:
Perform super-graceful shutdown of the socket on success.

This should guard against a RST being sent on success. It's possible
that the remote has sent data (ie: M_EOB) we would recv() after we
commit to ending the session. If the script terminates while there
is data to be read, this would result in sending a RST.

To prevent this, we call shutdown(sock, SHUT_WR) via setting is_writeable
to false (because that's how we roll), then recv() all data until the
remote closes the session, or the timeout passes.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/4322be29d519e065d4ba114a
Modified Files:
exec/load/binkp.js
Log Message:
Fix this.sock is undefined error.

Not sure how we get a successful shutdown after closing the socket,
but the issue was reported by altere as happening in the wild.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/3b166abe0fbe19a8bbfd8f01
Modified Files:
exec/load/binkp.js
Log Message:
The property is ver1_1, not ver_1.1

This should fix the binkd issue.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/b3a0377ee41701681e2723c2
Modified Files:
exec/load/binkp.js
Log Message:
And bump rev.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/93c9d7e0bf770a5a3b626ec4
Modified Files:
exec/load/binkp.js
Log Message:
Log the error on first-byte recv() timeout.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/8ef5e6c9dbaa2e086e2adc5a
Modified Files:
exec/load/binkp.js
Log Message:
Address "TypeError: buf is null" reported by Melkor

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/4dd32231f18bcb4f67833c36
Modified Files:
exec/load/binkp.js
Log Message:
Resolve undetected or infinitely-retried socket-send failures

My hub (1:218/700) is currently having what appears to be a TCP/IP
connectivity issue that was resulting in infinite "Send failure"
log messages and "We got an M_EOB, but there are still N files pending M_GOT" log messages.

I first added better socket-send failure detection (checking return value of sendCmd() and sendData() where needed) and then noticed that failure to send
a file was not detected (the sending.file.position is advanced even if sendData() fails), so now handling that condition too.

Also added more diagnostics around socket-send failures (is socket writable?) in this particular case, the socket is not writable and socket-send is returning 0.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/c3a41492a79aa3c6b3a41b37
Modified Files:
exec/load/binkp.js
Log Message:
More errno details in file open and socket-send failure warning log msgs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/0ea1ce1d2600b79a77d41b7e
Modified Files:
exec/load/binkp.js
Log Message:
Use socket.poll() to check socket for writability before send()

This is the real fix for infinite-wait on send() problem that was attempted
in commit f0127e9d457, but caused other issues. Thanks Deuce.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net