It keeps working when the link does not.
Most collaboration software treats the network as present and the outage as an error state. On a vessel, a rig or a field camp that is backwards: the link is the exception and the local network is the normal case.
The situation
Satellite and cellular links are expensive, slow and intermittent. Anything that syncs to a datacentre first is unusable at exactly the moment people need it.
Meanwhile the people on site are metres apart on a perfectly good local network, and are reduced to passing files on a USB stick because their tools insist on going via the cloud.
What MeshHold does about it
Peers first, internet if available
Nodes on the same LAN find each other and transfer directly at local speed. Nothing is routed through a distant server just to reach the next cabin.
Offline is a supported state, not a failure
The catalogue, the files you hold, chat history and the media library are all local. A node that has not seen the internet in a week is a working node, not a degraded one.
The expensive link carries only what it must
Content-addressed blocks mean a file that already exists on site is not fetched again, and the QoS scheduler keeps a bulk transfer from starving a voice call on the same uplink.
Calls and chat over the same mesh
Voice and video run between nodes over the mesh, so a conversation between two people on the same vessel does not leave it.
Where it does not fit
Every page like this one is a sales pitch. Here is the part that is not.
- This is not a maritime product. There is no certification, no hardened appliance, and no 24/7 line to call from the middle of the ocean.
- Someone on site has to be able to administer a Linux or Windows machine. It is not an appliance you rack and forget.
- Bandwidth-shaping helps a bad link; it cannot make a 128 kbit satellite connection carry a video call to shore.
Talk to us about it
There is one person on the other end, so a conversation is a conversation and not a discovery call.