• Debra (unregistered)

    A bad solution to a stupid problem which shouldn't have existed in the first place. Now that's what I call a "WTF premium".

  • Industrial Automation Engineer (unregistered)

    Fine. Tell that developer he should have used Unicode (set to a Chinese character set.)

  • Sole Purpose Of Visit (unregistered)

    I suppose you have to give in to idiots who say "We won't know the length of the message until we've sent it." (Grits teeth).

    But surely it's reasonable to suggest, under this (cretinous) rubric that there is a STX and ETX wrapper, and some sensible escape character mechanism in between? You could even add a checksum after the ETX, if you please.

    Oh look. Cut-down bisync.

  • NotAThingThatHappens (unregistered)

    Attitudes and hacks like this, is why we can't have nice things. Why your TV can communicate with 'a' soundbar, but not 'all' soundbars. Why the people that mean well, can never 'win' from the people that 'won't' and 'will not'.

  • The Other Jim (unregistered)

    I would NOT want to use anything that had been programmed by someone who thought '0' was zero! To me, that is the epitome of someone who doesn't know a thing about programming in the real world.

  • Hanzito (unregistered)

    That is depressing: they put their juniorest of junior developers on it, fresh from IoT boot camp, and then stuck by their guns. I hope that Remy, err, James, at least got a decent financial compensation out of it.

  • dusoft (unregistered)

    I though it was going to end by them implementing a length header, but no. I have ZERO questions, your honor.

  • The Dave G (unregistered)

    Sorry James, the spec says zero, not null terminating.

  • AnotherNonSignedIn (unregistered) in reply to The Dave G

    the spec says zero, not null terminating Which definition of zero? Binary 0 (i.e. NULL, 0x00, 0 decimal)? ASCII '0' (i.e. 0x30 / 48 decimal)? EBCDIC '0' (i.e. 0xF0 / 240 decimal)? There are a number of definitions of 'zero'. Only one of them seems sane to me in this context - I'm with James.

  • Sauron (unregistered)

    Those Initech people are horrifyingly incompetent.

    Frist of all, not knowing the difference between a zero character and a null character and not knowing the whole idea of string termination, that's just bad.

    Second, brainlessly implementing an obviously flawed termination with zero characters rather than asking, or even wondering whether that was a good idea, that's of an abysmal stupidity. The Initech dev could have given James a call and asked "Wait, are you guys sure about ending messages with zero characters?".

    Third, even in the insane case they absolutely wanted not to terminate messages with null characters, they could have decided of a more easily recognizable termination sequence (for example 10 zeros in a row) in a way that it would not risk conflict with the message content.

    What The Facepalm!

  • Richard B (unregistered)

    Okay, we'll terminate on a '0'. But you have to ensure that the character '0' is never used in the message.

    Also...what character set are we using?

    That this got as far as arbitration is the real WTF and is a perfect demonstration of non-technical people being put in charge of resolving a technical problem.

  • Bogolese (unregistered)

    A true WTF. Should have terminated with 0x57 0x54 0x46

  • Sole Purpose Of Visit (unregistered) in reply to Bogolese

    Wins! (I didn't even have to look those up in the ascii table ...)

  • Mr Bits (unregistered)

    Most of the recent Daily WTF articles have been, well, less than inspiring. Today's has restored my faith in WTF-ery.

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to Bogolese

    I think you mean 0x5A 0x6E 0x72 0x6F. As a bonus, it's not likely to appear naturally in the data!

  • see sharp (unregistered)

    Evidently the third-party arbitrator had not been properly vetted for technical literacy.

  • mithodin (unregistered) in reply to dusoft

    So you have 48 questions?

  • Vincent Archer (unregistered)

    That reminds me of an implementation of OSI networking protocols, back in 1988 or so. X400 (the real mail protocol, not that shitty SMTP stuff).

    You see it's painstakingly described, with all kinds of ASN1 stuff. And at one point, the standard called for the message number within the session. Starting at 1, and incrementing.

    But you see, where everywhere, it was clearly specified what coding were to be used, on that particular point, it was just "a number, starting with 1, and incrementing". Now, you had, based on the established encoding grammar, two ways of doing that.

    Way 1: Put a variable-sized integer, with a binary value. Way 2: Put a variable-sized ascii-encoded string, with the integer in it. In ascii.

    The vendor would not budge. It was a legal integer, therefore his implementation was correct. The email partner ignored all pleas of understanding, simply replying endlessly "your session failed protocol verification test; we're not opening your account until it passes".

    It took 4 years before the newest colored version of the OSI protocol book came out, and we could potentially point to the vendor where he wasn't compliant. Of course, by then, the vendor had closed all business relationship with us, since we never paid for a non-functional product, and the application that was supposed to be sending those messages had been cancelled.

  • WTFGuy (unregistered)

    @*Bogolese for the win. "WTF "is the ideal message terminator. Maybe with "FTW" on the front as a "message starts here" signal.

  • Brian (unregistered)

    Ah, yes, the fabled interchange format. What the spec said: ISO 8601 date and time with time zone. What they sent: "Thu 13 Oct 2022 03:59:30 PM America/New_York". Their president beat up our president. Sigh.

  • Mous (unregistered) in reply to AnotherNonSignedIn

    Indeed, notice how you did not quote the integer 0, but you did quote the character, "0". I think it's clear what the spec said.

  • Sole Purpose Of Visit (unregistered) in reply to I dunno LOL ¯\(°_o)/¯

    It may or may not be apocryphal, but back in the day some nitwit Microsoft programmer offered up a solution to Nathan Myhrvold. Myrhvold pointed out that it wasn't robust. The nitwit responded: "This would only go wrong about one in ten million times."

    To which, Myrhvold replied: "This is Initech. One in ten million times is next Tuesday."

    See you next Tuesday!

  • Yikes (unregistered)

    NULL is not a good termination character, nor is a series of 0's, since those are common in structured messages. It's unstated whether there's an expected and detectable intermessage break in time or closing of an outer OSI layer that doesn't exist intramessage, so I'll assume there isn't -- although it doesn't seem that detecting the start of the message is a problem, which would be a contradiction...

    There's also no restriction placed on message contents, which means there's absolutely no certain way to detect an end of message. Therefore, to me there seem to be two approaches which should both be used. First is a trailing checksum. To increase the probability that the checksum is actually a checksum, the first checksum value could be used for the second checksum value and so on, until the appropriate probability is achieved. The second is a recognizable opening pattern, e.g. 0x01020304, which enables high-probability recovery if synchronization is lost. Of course, if a developer likes this and decides to reuse it within a message.... you're screwed.

    Honestly the best solution is probably just to introduce a small, intermessage time delay or reuse a well-known OSI layer implementation, such as UDP, TCP, etc...

  • (nodebb)

    You say tomat0, I say tomat\0, let's call the whole thing off.

  • (nodebb) in reply to Debra

    Well they've only got themselves to blame, they should have used U+1F4A9 as the terminator and it'd be perfect for this, um, "protocol".

  • (nodebb) in reply to WTFGuy

    Maybe with "FTW" on the front as a "message starts here" signal.

    WTF
    Worse than failure (niche)
    What the f*** (internet parlance)
FTW
    For the win (on a good day)
    Start of message (maybe)
    F*** the world (after reading this article)
  • (nodebb)

    Wow, they've managed to out-WTF text-based protocols.

  • some guy (unregistered)

    We have not yet talked about how data almost inevitably becomes more, meaning that at some point, the parsing threshold will fail to work well enough.

  • MaxiTB (unregistered)

    Haha, I had once a discussion with a JS "developer" who tried to convince me that 0 and "0" are the same. I tried to explain to him that I already realized the difference when I was 8 years old, because I was upset that strings and numbers were not the same in BASIC, so smart-8-yr old me tried to come up with a language where it doesn't matter. I gave up after a week, realizing I was an idiot that still has a lot to learn.

  • David Hemming (unregistered)

    Which is why the spec should have used the words "Null Byte" as well as /0.

  • Dan Mercer (unregistered) in reply to Sole Purpose Of Visit

    In the 80's I worked for a company that produced front ends for IBM mainframes and compatible mainframes. We had a problem with bisync devices streaming in line noise if the ETX was damaged, and the entire box would fill up, primarily with FF's. My buddy put in a simple kludge, hold on to the message either until you get an ETX or the max size of the transmission was exceeded. If it was the latter, throw away the data and go through error recovery on the line. Development didn't like the solution as it didn't fit the Open Systems Interconnection model (OSI model) that everybody in telecommunications was forced to follow if they wanted to sell to the US govt. They put in their own fixes, time and time again, all OSI compliant, and they failed with the same symptoms over and over again. I left the company just as the whole market began to disintegrate and IBM finally put a dagger into the backs of all its competitors and the whole world ditched their IBM 3270 architecture for PC's with an Ethernet card. But, AFAIK my buddy was still sending out his kludge right up to the end.

  • Duke of New York (unregistered)

    And that Initech developer's name? Elon Musk.

  • (nodebb)

    I can solve the problem of ASCII 0s appearing in the text of the message. They can just scan the string and replace the occurrences of '0' with an escape sequence. '\0' would be ideal as it's the same size.

    I can't see that there would be any problems with that.

  • Jeremy (unregistered)
    Comment held for moderation.
  • (nodebb)

    I'd personally have not put the hack in. If messages got cut off it's the fault of the software sending them for including a 0.

  • Ariah (unregistered)
    Comment held for moderation.

Leave a comment on “Protocol Zero”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article