You totally can use Meshcore without repeater, and companions can be used like routers. This functionality can be enabled any time using one checkbox in app. It switches the radios to slightly different frequency and enables repeat mode in personal nodes, this gives you one small network. No repeater needed. And in this mode you don't clutter "main" mesh with your local mesh.
The main difference between Meshcore and Meshtastic is how telemetry is handled. In Meshcore to get telemetry the other party needs to request it, whereas in Meshtastic telemetry is sent in flood mode in configured intervals. That's why Meshtastic is better suited for (A)TAK [1]. But because Meshtastic sends telemetry anyway there is less and less airtime for chat messages, and it gets to the point where you can't talk to people. For small groups this is fine, for bigger groups/meshes this is no bueno.
If I have to modify settings and effectively kick myself off the mesh, then it doesn’t matter which protocol I use. By the same logic, you can just choose different settings on Meshtastic and get the same results, but you will not have anyone to mesh with.
Scroll Lock is really good key for that in my opinion. If your keyboard does not have it exposed then you can use some remapping program like https://github.com/jtroo/kanata
We are using 0mq for monitoring of electric vehicles fleet. Millions of messages every day (hundreds of GB), zero problems with bad internet connection (common in moving vehicles). Every sent message is received regardless of connectivity issues. Just a little implementation annoyances here and there but it is serving us well since 2015.
How does 0mq achieve that? For all I have read and tried to use of it, 0mq explicitly offers no message delivery guarantees, instead relying on your own implementation to achieve them. So, I don't doubt that your system works like you described, but I think you may be overvaluing 0mq's contribution to it.
Yes, I have read the guide pretty thoroughly. What all those things have in common is that they are your responsibility to implement - all that 0mq does is reconnect the socket, and queue up messages. Anything else that could give you reliability is either TCP's problem or yours. That includes timeouts, retransmit, ACKs, keepalives, heartbeats, rate control, message storage, everything that ensures reliability - with 0mq you get to implement it. Lazy pirate indeed.
We implemented KISS state machine based on TCP timeouts and server response.
Pseudocode:
Send msg to server
if socket timeout:
reinit socket and send again
Recv from server
if recv.msg != 'ok':
send again
else
remove msg from storage
One message has from few to few hundreds Kilobytes. Messages are stored and sent as custom binary data for better compression (better that protobuffs).
ZMQ takes complexity of raw tcp sockets away and this is what we needed it for. As much and as little.
This leaves higher application code to handle duplicated messages. It also does not handle cases where the client connects later than the server send, but would still like to receive the server messages. It also doesn't handle rate control (overwhelming the network).
These may all be fine for your application, and then 0mq is an excellent fit. But I think that for most applications, having some kind of pre-implemebted solution to all of these problems, even with slightly more overhead, is extremely valuable.
Someone is sending spam via YouTube. Link is already disabled. Sent from: https://vgy.me/NdJHGg.png. Really creative. Think twice before You click anything.
The main difference between Meshcore and Meshtastic is how telemetry is handled. In Meshcore to get telemetry the other party needs to request it, whereas in Meshtastic telemetry is sent in flood mode in configured intervals. That's why Meshtastic is better suited for (A)TAK [1]. But because Meshtastic sends telemetry anyway there is less and less airtime for chat messages, and it gets to the point where you can't talk to people. For small groups this is fine, for bigger groups/meshes this is no bueno.
[1] https://tak.gov/ - (A) stands for Android app.
reply