search

bictorv / chaosnet-bridge

Bridge program for various Chaosnet link implementations.
Apache License 2.0
22 stars 5 forks source link

The TIME protocol has a year 2036 problem. #30

Open larsbrinkhoff opened 1 year ago

larsbrinkhoff commented 1 year ago

Still 13 years to go, but maybe something to consider soon. CC @ams

ams commented 1 year ago

There is plenty of space in the TIME protocol to handle that. I think at some point, we will have to start breaking existing protocols slightly to accommodate the future... maybe it can be done in a nice way.

For example,

https://github.com/bictorv/chaosnet-bridge/blob/f71ac772de1c17b3fdba864789eed01b74eb3d3a/contacts.c#L221-L224

Just adding two more bytes in LSB order should work just well enough for everything extending things good enough, or even going naughty and using 64-bit.

larsbrinkhoff commented 1 year ago

Seems nice. Signed 64-bit, that should cover a lot.

bictorv commented 1 year ago

(Why don't I get notifications about new issues and pull requests in my own repo? What setting do I need to change?)

I've been thinking about this too, but more along the lines of "let it overflow, and interpret low values as relative to 2036". It would be backwards compatible, and for the protocol it would work, differently from datestamps etc (which need to represent old dates too).

More people than us should have been thinking about it?

bictorv commented 1 year ago

Actually both fixes are compatible, if the more significant bytes are sent after the least four. Except possibly some implementation might check the data length. Open Genera might have problems, but not CADR, Lambda, ITS.

bictorv commented 1 year ago

More people than us should have been thinking about it?

Of course the same problem occurs in the TCP/UDP TIME protocol (port 37, RFC868). For Chaos, avoiding ambiguity can be done by adding a parameter to the RFC packet, e.g. "TIME 2", to ask for a 64-bit time, but it's less doable in the less flexible TCP/UDP. There, I would suppose the solution would be to interpret "low values" relative to 2036-02-07 06:28:16. (Or start using a new port, but that's really awkward. Or try to revise RFC868, which could start an interesting discussion I suppose!)

larsbrinkhoff commented 1 year ago

Is the "Internet" RFC868 protocol still in use? If so, is anyone else trying to fix it? Wikipedia says "this function was superseded by the Network Time Protocol", so maybe not. We should probably assume Chaosnet is alone in this.

CC @dseagrav; what's the LMI situation?

bictorv commented 1 year ago

The LambdaDelta system can read the time from the emulated SDU subsystem (which reads it from the host), or use the TIME protocols.

ams commented 1 year ago

Similar for Genera, it can use TIME if you are on Chaos .. but I suspect since the advent of Open Genera the amount of Slimebolix machines on the Chaosnet are nil. I wouldn't worry about them...

As for revisiting RFC 868 .. I'm for that!

bictorv commented 1 year ago

RFC868 is still a standard, although the precision is way too poor for "modern" situations where timing needs to be more exact (e.g. in cryptographic settings). Implementing NTP in "our type" of systems would be overkill, e.g. given that the alternative when no TIME servers can be contacted is to ask the "operator" to input the time (with even lower precision).

Genera can use TIME, but OG on Linux doesn't really support Chaos since it uses tun devices which only do IP, as far as I know.

There are widely available implementations if the RFC868 protocol, currently, and they might be useful for "people like us" when not using Chaosnet (e.g OG on Linux), or "stand-alone" LambdaDelta installations (without cbridge - they can use the SDU but might not). However to make a revised RFC868 widely implemented seems a challenge (although we have a couple of years to succeed).

I would propose

But not in that order, possibly the reverse.

ams commented 11 months ago

For maybe, future reference: https://www.ietf.org/proceedings/62/slides/editor-0.pdf ;-)