5 ms·

Also, since SSMP is completely text-based, does that mean the only way to send binary data is to base64-encode it? Or does it support a length header or chunki

Also, since SSMP is completely text-based, does that mean the only way to send binary data is to base64-encode it? Or does it support a length header or chunking similar to HTTP?

dsr_ 11y ago
It's slightly worse than that: a payload can be any 8-bit data... except a LF character. Which is to say, you will need to either escape or quote it in some way, which is to say you are on your own. It might have been cleaner to specify base64 encoding or length-prefaced payloads (say, 16 bit int preface indicating length in bytes). As it is, you are on your own.
vonsnowman 11y ago
base64 is the preferred way but any 8-bit encoding that doesn't use LF would also work. There is no support for a length header or chunking as SSMP is designed with small messages in mind.
- dsr_ 11y ago
  I suggest that you call it the default in your spec and include it in your reference implementation, then.
- teacup50 11y ago
  Why wouldn't you just include a length field on strings/bytes, allowing the protocol to be "binary clean" and avoid the base64 problem entirely? This is one of the most annoying things about XMPP (even sending contact photos hits this!), so if replacing XMPP ...
  - vonsnowman 11y ago
    A big advantage of LF-delimited over length-prefixed messages is netcat/telnet-friendliness. That was more valuable to us than being binary-clean as our use cases do not involve sending large binary messages.
    - mjevans 11y ago
      I think you might want to make a distinction between a stream packet and a completed message. If you're going for telnet compatibility then you'll want to terminate packets in CR+LF, but possibly expect to see only CR or LF from the client (ASCII mode). Your stream could either be stateful (a message is always sent complete and in order, even if it takes multiple stream packets) or stateless* (different messages might have stream packets consecutively). It would be more future proof if you started with a message grammar and then defined your protocol on top of that.
    - teacup50 11y ago
      A binary-friendly client would be a hundred lines of code at most, versus inefficiency for a pretty standard protocol use-case forever.
    - IshKebab 11y ago
      You know you could have a length-prefix and a new-line. Best of both worlds.

Also, since SSMP is completely text-based, does that mean the only way to send binary data is to base64-encode it? Or does it support a length header or chunking similar to HTTP?

dsr_ 11y ago

It's slightly worse than that: a payload can be any 8-bit data... except a LF character. Which is to say, you will need to either escape or quote it in some way, which is to say you are on your own. It might have been cleaner to specify base64 encoding or length-prefaced payloads (say, 16 bit int preface indicating length in bytes). As it is, you are on your own.

vonsnowman 11y ago

base64 is the preferred way but any 8-bit encoding that doesn't use LF would also work. There is no support for a length header or chunking as SSMP is designed with small messages in mind.

dsr_ 11y ago
I suggest that you call it the default in your spec and include it in your reference implementation, then.
teacup50 11y ago
Why wouldn't you just include a length field on strings/bytes, allowing the protocol to be "binary clean" and avoid the base64 problem entirely? This is one of the most annoying things about XMPP (even sending contact photos hits this!), so if replacing XMPP ...
- vonsnowman 11y ago
  A big advantage of LF-delimited over length-prefixed messages is netcat/telnet-friendliness. That was more valuable to us than being binary-clean as our use cases do not involve sending large binary messages.
  - mjevans 11y ago
    I think you might want to make a distinction between a stream packet and a completed message. If you're going for telnet compatibility then you'll want to terminate packets in CR+LF, but possibly expect to see only CR or LF from the client (ASCII mode). Your stream could either be stateful (a message is always sent complete and in order, even if it takes multiple stream packets) or stateless* (different messages might have stream packets consecutively). It would be more future proof if you started with a message grammar and then defined your protocol on top of that.
  - teacup50 11y ago
    A binary-friendly client would be a hundred lines of code at most, versus inefficiency for a pretty standard protocol use-case forever.
  - IshKebab 11y ago
    You know you could have a length-prefix and a new-line. Best of both worlds.