Need ideas for data transmission

again not specific to Xojo, but more towards networking in general.

Imagine a number of devices (could be anything tablets, desktops, phones) each running an app that broadcasts via Bluetooth, and each other device can recieve and react to that data (fyi, the idea is a multi-player game). When a user makes a move on their device it needs to broadcast the required information, so that all the other devices can register that changes and stay in synch.

What I am trying to do is come up with a simple, yet comprehensive “packet” that can be used… As well as some way to determine if things got “lost”.

This isn’t a client/server set up… its a peer-to-peer multicast… so everyone sends out their data and everyone recieves it…

I was thinking something along the lines of

  • byte 0 : sender id
  • byte 2 : recipient id (255 for all, in case I want targeted packets later)
  • byte 3 : action command
  • byte 4 - x : action information
  • byte x+1 END OF PACKET marker

So for example : 1XR3# might be user #1 sends to all users (X) a “rotate of 3 degrees” command , “#” is Endofpacket

Due to the nature of the BT classes, there is no “interim” data recieved… the packet arrives as a string or it doesn’t, and if it doesn’t there is no way to know that it should have.

What I do not know is how fast this communication really is, and what the chances and ramifications might be of devices getting incoming information is a different order.

I would like this to be able to support up to 8 devices at least…

This type of communication is a new field of study for me, so if anyone has any ideas, I’m open

EDIT : seems I should add some type of sequence value in the packet. so the recipents will know if this data is older than something it already got

I had same “problem” months ago, I’d googled and create my solution “BinaryMessage” based on ProtocolBuffers and msgpack.

The idea is a step forward, is serialize the packet into/from a class, In my case I use ‘.WriteTo(…)’ and ‘.ReadFrom(…)’ is abtract so you can used to trasmission or save data to disk, My main concern is the bandwidth, ex. the next message (packet) in JSON has 179bytes:

{ "name": "John Doe", "id": 5, "email": "john@server.com", "phones": [ {"type": 1, "number": "123 4567"}, {"type": 2, "number": "555 5555"} ] }

In binaryMessage has 66Bytes.

PM if you would test/try my implementation.

I would have a message ID number in your packet that increments. That way, you can determine if there are missed packets in between the received messages (by the receiving party). Not sure the course of action if you do miss a message, other than notify the user of a lost or intermittent connection. I would also include a check sum for the whole message to ensure data integrity.

The flow of messages will be fairly constant, so a “missed” message may not be an issue, but an out of sequence one would be
checksum won’t be required, as the BT framework that I’m using insures that if it gets to the destination, it is complete

You may want to look at a token ring type of protocol, to ensure that messages get sent and received in a deterministic fashion.

The incrementing id would help determine sequence issues only if each party has a unique id as well. With the current proposal, Client A can not tell the difference between packet 1 from Client B and packet 1 from Client C.

It also runs the risk of running out of space. For example, if using a UInt8, you can only send 255 packets before reusing number 1. So recipients need to be aware of that as well.

Another potential option is to daisy chain UUIDs. So the first packet has a uuid for its id, and null for its last_id. Second packet has a new uuid for its id, and last_id is the uuid of the first packet. This avoids the reuse issue, but probably isn’t worth the complexity.

Byte 0 - Sender ID
plus I just discovered that the message sending method already attached a unique “sender id” that the framework creates
so all I need to worry about is the informational content, and using a UInt64 will be more that enough to not worry about rollover :slight_smile: (about 2500 years or so)

D’oh. Nevermind me then.

Dave,

If you use a restful approach you will have the fastest protocol delivery of frames with the protocol you are creating. By using TLS/JSON you will also be able to utilize a messaging protocol sequence of your choosing without having to be tied to an old school structured fixed header framing.

I created many of my own proprietary protocols using a structured fixed header framing model and RestFUL implementations using JSON. The latter is much more flexible and easier to implement as you know with your JSON/XML experience.

The transmission method is fixed… it is the iOS MultipeerConnectivity framework

Ah understood - I didn’t realize or read close enough to see the framework cited.

Good luck buddy.