PDP-10 / supdup

Community maintained SUPDUP client for Unix
Other
16 stars 8 forks source link

Support for using Chaosnet streams (provided by cbridge). #23

Closed bictorv closed 3 years ago

bictorv commented 3 years ago

f the host parameter given can be on Chaosnet (based on DNS or that it's a valid 16-bit chaos address, and that cbridge allows a connection), connect using the stream interface of cbridge, else use Internet as usual.

Also send three extra Supdup variables (supported by ITS), and some minor things.

larsbrinkhoff commented 3 years ago

I tested a regular TCP supdup to up.update.uu.se, and it didn't work. The old supdup works.


$ ./supdup up.update.uu.se
Trying 130.238.19.215 port 95 ...Connected to up.update.uu.se.
Escape character is "C-^".
UPdate KLH-10
Connection closed by up.update.uu.se.
bictorv commented 3 years ago

"it works for me", so could you be more specific about what doesn't work? Possibly run with -d when it doesn't work?

larsbrinkhoff commented 3 years ago

Here's the output when run with -d. If you like, you can get an account on my machine.

(Side note: Do we want SAIL characters or CR LF here?)


connect(server): No such file or directory
setsockopt (SO_DEBUG): Invalid argument
Trying 130.238.19.215 port 95 ...Connected to up.update.uu.se.
Escape character is "C-^".
State: 0, Incoming: 0125. Translation: U
State: 0, Incoming: 0120. Translation: P
State: 0, Incoming: 0144. Translation: d
State: 0, Incoming: 0141. Translation: a
State: 0, Incoming: 0164. Translation: t
State: 0, Incoming: 0145. Translation: e
State: 0, Incoming: 040. Translation:  
State: 0, Incoming: 0113. Translation: K
State: 0, Incoming: 0114. Translation: L
State: 0, Incoming: 0110. Translation: H
State: 0, Incoming: 055. Translation: -
State: 0, Incoming: 061. Translation: 1
State: 0, Incoming: 060. Translation: 0
State: 0, Incoming: 015. Translation: circled plus
State: 0, Incoming: 012. Translation: delta
UPdate KLH-10
Connection closed by up.update.uu.se.
bictorv commented 3 years ago

It's gcc which treats a plain "char" declaration as "unsigned char". Changing inits from "char" to "signed char" makes it work also on Linux. (Why does it do that? Is it some new stupid standard?)

Sorry, not quite sufficient: being in a hurry, just #if 0 ... #endif around adding the new Supdup variables at the end of sup_term() makes it, for now.

(The translation is not actually done until the first TDNOP, as per one of my recent patches.)

ams commented 3 years ago

It's gcc which treats a plain "char" declaration as "unsigned char". Changing inits from "char" to "signed char" makes it work also on Linux. (Why does it do that? Is it some new stupid standard?)

The sign of 'char' is unspecified in C -- if you depend on the sign of char you must specify it. This has always been the case in C.

larsbrinkhoff commented 3 years ago

Oh, a language lawyer thread!

It's certainly true that the signedness of char in C is unspecified, but an argument can be made that changing this choice on a particular platform isn't a good practice. Programs that once worked may suddenly break, potentially making lots of people unhappy or worse, silently hiding security problems.

ams commented 3 years ago

Oh, a language lawyer thread!

It's certainly true that the signedness of char in C is unspecified, but an argument can be made that changing this choice on a particular platform isn't a good practice. Programs that once worked may suddenly break, potentially making lots of people unhappy or worse, silently hiding security problems.

Welcome to the world of C. :-)

bictorv commented 3 years ago

Next time I have too much time, I'll rewrite everything in a high-level language...

larsbrinkhoff commented 3 years ago

Portable CLU maybe?

larsbrinkhoff commented 3 years ago

I don't know if it's applicable here, but ITS also handles 40k, 50k, and 80k bits/s.

bictorv commented 3 years ago

I know (now), but "unix" doesn't. And really, nobody seems to care. :-)

ams commented 3 years ago

FWIW, this breaks on OpenBSD. Mostly due to the fact that -lresolv doesn't exist there (nor on some other BSDs), normally these days the libresolv stuff is provided directly by libc both on BSDs and GNU systems but OS X seems to not have followed suite? Dynamically adding -lresolv to the linker line is slightly tricky to do in some form of portable Make -- since everyone wants to be special.

bictorv commented 3 years ago

autoconf, anyone? Also, feel free to add some #ifdef to avoid the DNS code and just look for numeric chaos addresses? But also, not all resolver libraries are equivalent, as I discovered implementing the DNS part of cbridge. I forgot the details, I'm afraid, but if you would try to get it working on OpenBSD you might discover?

ams commented 3 years ago

I'd like to avoid autoconf/automake, mostly since this is such a tiny program. And it brings its own set of complications (generating the configure scripts, on OpenBSD one needs to export a few environment variables for it to work well, etc)... But I'll see what I can figure out both for supdup, and cbridge (where I think I have some autoconf hackery pending?).