CCSMB-5: PCM Audio Transmissions over modem

[EmmaKnijn]

Here is CCSMB-5, suggestions are welcome!

[tomodachi94]

Might want to elaborate on this later on.

[EmmaKnijn]

znepb suggested that that might be a standard as well

[MasonGulu]

There should be a field that uniquely identifies a packet as following this spec. With the addition of that, the field names could be simplified into station, and title.

[tomodachi94]

Should we make clients reject packets from servers with an invalid protocol field in order to be compliant?

[EmmaKnijn]

Should we make clients reject packets from servers with an invalid protocol field in order to be compliant?

It would create more stability, I'm expecting to expand this someday in another standard so that should be good

[EmmaKnijn]

I think we're ready right?

[MasonGulu]

Wait for more feedback.

[MCJack123]

This feels like a very rough draft of a proper standard. Maybe I'm just picky, but standards should clearly explain every relevant part of the standard, and define strict rules where implementors can quickly determine whether they match or not. There's still a lot of ambiguity here, and as-is describes more of a loose data format to follow instead of a proper end-to-end protocol.

One thing I'm a bit stuck on in general is channel choice - having limited channel choice is a bit weird when we have Rednet able to not only specify (theoretically) infinite server endpoints, but it also doesn't have to worry about channel collisions, as the ID of the computer uniquely identifies the source of the data. A drawback is that by using Rednet, every station in the world will always be sending Rednet messages to every computer using Rednet, which isn't quite desirable. An alternative may be to use the current method, but with the computer ID to identify the server instead.

As for discovery, I propose a broadcast message to query what stations are available/in range. This can work like GPS, where a message is sent on a standardized channel, and all servers reply with their metadata, including channel number (in the reply channel field?). This would enhance this otherwise simple protocol with more user-friendly features. It would also allow users to use the server name to connect, instead of having to remember the specific channel number (imagine having to remember an IP instead of domain name for every site); as well as the ability to have full channel listings and browsers.

---

I think we're ready right?

Standards should be in the queue for at least a week for all kinks to be worked out by as many people as possible. RFCs take years to pass to make sure that there's been plenty of consensus on every exact detail.

[MCJack123]

This is worded a bit informally; I'd prefer it to use full sentences in bullet points or an ordered list.

We should also mention RFC 2119 if using keywords like "MUST", "SHOULD", etc.

[EmmaKnijn]

Could you write an example, I feel like writing the same In order to be compliant the in 5 bullet points is a bit redundant

[EmmaKnijn]

Some code examples would be nice too, especially basic clients.

I'll work on that once it's pretty much set in stone

It also needs some language improvement to have a professional tone.

I agree

[EmmaKnijn]

My biggest concern with this is that there is no validation whatsoever. Anyone could easily pretend to be the radio station and send whatever they want.

I honestly don't know if this is fixable over CC, if you compare it to real life, anyone with a Pi can transmit over FM

[EmmaKnijn]

and personally the thing i dont like is it does not contains what happens if a server were to transmit early and what if a client joins mid-song, is the client expected to wait or ... i propose a packet ID system packets count UP, thatway clients can keep watch for the "next packet" and if it recieves packet 0 then we know that the next song has startd and we can reset the counter to 0 and also a server-bound packet to request re-send latest audio packet (in the case a client connects mid-song)

Packets are up to 2.7s long, It would take like 6 seconds at max to get a solid connection

[tomodachi94]

@EmmaKnijn @MCJack123 what if stations broadcasted some information like station name, channel number etc over a specified channel every, say, 15 seconds, and had a specific range of channel IDs that are specified for radio but aren't hard coded?

[MCJack123]

what if stations broadcasted some information like station name, channel number etc over a specified channel every, say, 15 seconds, and had a specific range of channel IDs that are specified for radio but aren't hard coded?

I'd rather make it be a request-response system - the client sends a request for servers on a standardized channel, and all servers respond with their names/channel number. Broadcasting to nobody is just wasted CPU time.

[Erb3]

You have a lot of feedback to work with here, and a fair bit of work to do. I would also request that do not make tons of GitHub comments for responding, when you can quote multiple messages in one message.

cc @EmmaKnijn

---

I am all for the idea for server discovery. A client sends a message on a specific channel, and all stations reply on that channel with names / channel.

---

I am not sure how I feel about encryption or signing of the radio. Afaik it would take valuable time to verify this before playing the audio?

[EmmaKnijn]

Added a bunch of things, feel free to have another look

[Erb3]

Still a lot of unresolved conversations here. Not ready for merge.

[EmmaKnijn]

Alright, I iterated again. Feel free to have another look.

erb3 has left CCSMB

[EmmaKnijn]

Should we index this as
buffer.fr
buffer.fl
buffer.fc
etc...