I'm trying to fetch the login screen for a MUD and having some issues.

If I use telnet aardmud.org 4000 then it connects and.
nc aardmud.org 4000 produces some junk characters and then displays the login screen. I guess they're some sort of terminal detection or negotiation. tcpdump output doesn't look like telnet negotiation.

Now with js I'm trying this:

var sock = new Socket(SOCK_STREAM);
try { sock.connect('aardmud.org',4000,5) }
catch(e) {
writeln(e);
exit();
}
sock.is_connected show true. So let me check if there's some data waiting for me.

sock.data_waiting shows false
sock.ndata shows 0
sock.poll(0,true) shows the socket is set for reading.

now if I use sock.recvline I get a line of data. So if there's data waiting, why wouldn't data_waiting tell me?

Maybe I am misunderstanding how it all works.

What would be the best way of getting the data upto the point where I am asked to login?

---
þ Synchronet þ End Of The Line BBS - endofthelinebbs.com

Re: Is there a bug in Socket.data_waiting ?
By: nelgin to Digital man on Wed Feb 21 2024 11:30 am

I'm trying to fetch the login screen for a MUD and having some issues.

If I use telnet aardmud.org 4000 then it connects and.
nc aardmud.org 4000 produces some junk characters and then displays the login screen. I guess they're some sort of terminal detection or negotiation. tcpdump output doesn't look like telnet negotiation.

Now with js I'm trying this:

var sock = new Socket(SOCK_STREAM);
try { sock.connect('aardmud.org',4000,5) }
catch(e) {
writeln(e);
exit();
}
sock.is_connected show true. So let me check if there's some data waiting for me.

sock.data_waiting shows false
sock.ndata shows 0
sock.poll(0,true) shows the socket is set for reading.

now if I use sock.recvline I get a line of data. So if there's data waiting, why wouldn't data_waiting tell me?

I would expect data_waiting to be true.

Maybe I am misunderstanding how it all works.

What would be the best way of getting the data upto the point where I am asked to login?

It might be best to figure out what that initial handshake is and deal with that first.
--
digital man (rob)

Synchronet "Real Fact" #58:
The last version of Synchronet to run on MS-DOS and OS/2 was v2.30c (1999) Norco, CA WX: 61.7øF, 78.0% humidity, 0 mph SSW wind, 0.75 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Is there a bug in Socket.data_waiting ?
By: Digital Man to nelgin on Wed Feb 21 2024 11:25:52

now if I use sock.recvline I get a line of data. So if there's data waiting, why wouldn't data_waiting tell me?

I would expect data_waiting to be true.

Definately false.
$ cat socktest.js

'use strict';
load("sbbsdefs.js");
load('sockdefs.js');


var sock = new Socket(SOCK_STREAM);
try { sock.connect('aardmud.org',4000,5) }
catch(e) {
writeln(e);
exit();
}

writeln("data? " + sock.data_waiting);
sock.close();
bbs@bbs:/sbbs/xtrn/mudlist/scripts$ jsexec -n socktest.js
data? false

It might be best to figure out what that initial handshake is and deal with that first.

I did find the telnet negotiation strings in the end, they were a bit buried, so that is sorted.

---
þ Synchronet þ End Of The Line BBS - endofthelinebbs.com

Re: Is there a bug in Socket.data_waiting ?
By: nelgin to Digital Man on Wed Feb 21 2024 01:52 pm

Re: Is there a bug in Socket.data_waiting ?
By: Digital Man to nelgin on Wed Feb 21 2024 11:25:52

now if I use sock.recvline I get a line of data. So if there's data waiting, why wouldn't data_waiting tell me?

I would expect data_waiting to be true.

Definately false.
$ cat socktest.js

'use strict';
load("sbbsdefs.js");
load('sockdefs.js');

var sock = new Socket(SOCK_STREAM);
try { sock.connect('aardmud.org',4000,5) }
catch(e) {
writeln(e);
exit();
}

Socket.connect() doesn't throw an exception upon failure (it just retuns false on failure) - so why the try/catch here?

writeln("data? " + sock.data_waiting);
sock.close();
bbs@bbs:/sbbs/xtrn/mudlist/scripts$ jsexec -n socktest.js
data? false

I wrote a quick little test here and it shows Socket.data_waiting working as expected:

var sock = new Socket();
if(!sock.connect("vert.synchro.net", 23)) {
alert("connect failure " + sock.error_str);
exit(1);
}
while(sock.is_connected) {
if(sock.data_waiting)
print(JSON.stringify(sock, null, 4));
}
--
digital man (rob)

Sling Blade quote #10:
Morris: I stand on the hill, not for thrill, but for the breath of a fresh kill Norco, CA WX: 53.7øF, 87.0% humidity, 1 mph NNW wind, 0.19 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Is there a bug in Socket.data_waiting ?
By: Digital Man to nelgin on Wed Feb 21 2024 20:24:51

'use strict';
load("sbbsdefs.js");
load('sockdefs.js');

var sock = new Socket();

if(!sock.connect('vert.synchro.net',23)) {
writeln('Connect failure ' + sock.error_str);
exit(1);
}

writeln("ic: " + sock.is_connected);
print(JSON.stringify(sock, null, 4));

So, if I go with this:

ic: true
"error_str": "Success",
"is_writeable": true,
"is_writable": true,
"data_waiting": false,
"nread": 0,

Shouldn't matter if I'm not in a loop right? When I connect the a socket there's data waiting for me as evidenced by netcat.

$ nc vert.synchro.net 23

Synchronet BBS for Win32 Version 3.20
Telnet connection from: 192.138.210.158
Resolving hostname...
±±±±±±±± ±±±±±±'
_ _
Synchronet BBS for Win32 Version 3.20 Copyright 2022 Rob Swindell ^[[?6c^[[49;98R^[[49;1R^C

INterestingly, it seems vert does telnet negotiation after already sending some text.

---
þ Synchronet þ End Of The Line BBS - endofthelinebbs.com

Re: Is there a bug in Socket.data_waiting ?
By: nelgin to Digital Man on Thu Feb 22 2024 12:42 am

Re: Is there a bug in Socket.data_waiting ?
By: Digital Man to nelgin on Wed Feb 21 2024 20:24:51

'use strict';
load("sbbsdefs.js");
load('sockdefs.js');

var sock = new Socket();

if(!sock.connect('vert.synchro.net',23)) {
writeln('Connect failure ' + sock.error_str);
exit(1);
}

writeln("ic: " + sock.is_connected);
print(JSON.stringify(sock, null, 4));

So, if I go with this:

ic: true
"error_str": "Success",
"is_writeable": true,
"is_writable": true,
"data_waiting": false,
"nread": 0,

Shouldn't matter if I'm not in a loop right?

Yes, it matters. The first time (or several) through the loop, there's not going to be any data waiting.

When I connect the a socket
there's data waiting for me as evidenced by netcat.

$ nc vert.synchro.net 23

Synchronet BBS for Win32 Version 3.20
Telnet connection from: 192.138.210.158
Resolving hostname...
±±±±±±±± ±±±±±±'
_
_
Synchronet BBS for Win32 Version 3.20 Copyright 2022 Rob Swindell ^[[?6c^[[49;98R^[[49;1R^C

netcat is polling for received data (in a loop, like the example I pasted). That data is not just immediately available upon connection.

INterestingly, it seems vert does telnet negotiation after already sending some text.

Yup. Telnet commands can be sent at any time.
--
digital man (rob)

This Is Spinal Tap quote #38:
Artie Fufkin: I'm not asking, I'm telling with this. Kick my ass.
Norco, CA WX: 51.2øF, 91.0% humidity, 0 mph ESE wind, 0.16 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Is there a bug in Socket.data_waiting ?
By: nelgin to Digital man on Wed Feb 21 2024 11:30 am

I'm trying to fetch the login screen for a MUD and having some issues.

If I use telnet aardmud.org 4000 then it connects and.
nc aardmud.org 4000 produces some junk characters and then displays the login screen. I guess they're some sort of terminal detection or negotiation. tcpdump output doesn't look like telnet negotiation.

Now with js I'm trying this:

var sock = new Socket(SOCK_STREAM);
try { sock.connect('aardmud.org',4000,5) }
catch(e) {
writeln(e);
exit();
}
sock.is_connected show true. So let me check if there's some data waiting for me.

sock.data_waiting shows false
sock.ndata shows 0

You're not going to have data waiting to read *immediately* after a connect.

sock.poll(0,true) shows the socket is set for reading.

now if I use sock.recvline I get a line of data. So if there's data waiting, why wouldn't data_waiting tell me?

Socket.recvline() waits for data (an entire "line" of it, in fact). That's why it has a timeout parameter (that defaults to 30 seconds).
--
digital man (rob)

Synchronet/BBS Terminology Definition #19:
DCD = Data Carrier Detect
Norco, CA WX: 50.7øF, 91.0% humidity, 0 mph E wind, 0.16 inches rain/24hrs
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net