Clients have no way to reliably send messages in order (other than serialising each and every send)

[ara4n]

In the current CS API, there is no way to assert an ordering of /send calls (EDIT: other than sending each and everyone in series, waiting for the 200 before you make the next request). Therefore if one request happens to take longer than another, or get delayed due to network conditions, there is no efficient way to require that ordering is preserved. This happens particularly often when recovering after a network outage.

I think our options are:

1. To change /send to (optionally) include a pointer to the preceeding message in order to express a partial ordering.
2. To send messages via websockets or some other ordered transport
3. To order based on timestamps (ugh)

It feels like option 1 is the least worst option to me.

This would solve chronic bug 44: "Users expect messages to always be sent (and received) in the order that they were written."

[richvdh]

In the current CS API, there is no way to assert an ordering of /send calls.

well, clients can send messages in series (ie, not make a second /send request until the first one completes successfully). Which was what I thought our clients did, tbh...

[MTRNord]

Mostly wondering: why is waiting on the previous request to finish not an option for clients? Sure it may be a little slower but wouldn't the wait time just move to a different part of the chain as there is a reason the request takes longer in the first place?

[ara4n]

true. i guess the only problem is that it means your throughput of messages is limited to one per RTT. but given we throttle messages by default pretty slowly, perhaps that's not a disaster.

[MadLittleMods]

Related to #260 (could be a duplicate with some adjusting)

[richvdh]

true. i guess the only problem is that it means your throughput of messages is limited to one per RTT. but given we throttle messages by default pretty slowly, perhaps that's not a disaster.

Given this, I'm going to close it for now. If the RTT becomes a real bottleneck (rather than server-side throughput), then we can reopen with something more focussed.