User Tools

Site Tools


mosh:transports

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
mosh:transports [2025/06/25 15:44] moshmosh:transports [2026/06/10 13:55] (current) mosh
Line 1: Line 1:
 +<WRAP important>
 +This page is retained for historical reference and may not reflect the current MOSH/IMC/MTRP architecture.
 +See [[guide:architecture_map]] for the current model.
 +</WRAP>
 +====== MOSH Transports ======
 +
 ===== OSI Model -- Quick Overview ===== ===== OSI Model -- Quick Overview =====
  
Line 11: Line 17:
   * Layer 1 - Physical   * Layer 1 - Physical
  
-Depending on the type of transport being used, MOSH transmits at different layers of the OSI model. It is important to know that in all cases, MOSH implements its own framework of security.+Depending on the underlying transport, MOSH messages may be transmitted starting at different layers of the OSI model. For example, when using ESP-NOW, communication operates close to Layer 2 (Data Link), whereas with Wi-Fi + TCP, MOSH operates above Layer 4 (Transport). It is important to know that in all cases, MOSH implements its own framework of security.
  
 ===== Encapsulation ===== ===== Encapsulation =====
  
-Another key concept in network communications is that of encapsulation. Simply put, encapsulation is the process of wrapping existing data in new data. In OSI (and TCP/IP), data at higher layers is encapsulated by data at lower layers. Consequently, MOSH messages are encapsulated, or wrapped, by other lower-level protocols used by transports.+Another key concept in network communications is that of encapsulation. Simply put, encapsulation is the process of wrapping existing data in new data. In OSI (and TCP/IP), data at higher layers is encapsulated by data at lower layers.
  
-Depending on the transport being used, MOSH may rely on the functionality of these existing protocols for things like reliable message delivery. For example, TCP (used in IP networks) ensures messages sent by one node are received by the destination nodeIn this scenario, MOSH doesn't need to perform that function since it's included it the transport.+Depending on the transport being used, MOSH may rely on the functionality of these existing protocols for things like reliable message delivery. MOSH encapsulates its application-layer messages within the payload of lower-level protocols like ESP-NOW, TCP, or UART. Depending on the transport, reliability, ordering, and error correction may be handled by the underlying protocol (e.g., TCP), or left to MOSH to implement (e.g., ESP-NOW or UART).
  
 ===== MOSH Transports ===== ===== MOSH Transports =====
Line 26: Line 32:
   * Espressif ESP-NOW(V1)   * Espressif ESP-NOW(V1)
   * Espressif ESP-NOW(V2)   * Espressif ESP-NOW(V2)
-  * WiFi+  * Wi-Fi
   * Serial   * Serial
 +  * Bluetooth (future)
 +  * nRF24L01 (future)
 +  * nRF52840 (future)
 +  * LoRa (future)
 +
 +MOSH is designed to abstract the transport layer so that core functionality (messaging, routing, automation) remains consistent regardless of whether messages are transmitted via ESP-NOW, Wi-Fi, Serial, or future transports.
  
 ==== ESP-Now (v1 and v2) ==== ==== ESP-Now (v1 and v2) ====
  
-ESP-NOW is a protocol designed by Espressif to be a connectionless, low-overhead, peer-to-peer protocol. It does not natively ensure delivery of messages, or include any built-in security featuresAs far as MOSH transports go, ESP-NOW is a sort-of middle ground -- offering maximum message lengths of 250 bytes in version 1and up to 1470 bytes in version 2.+ESP-NOW is a protocol designed by Espressif for low-overhead, connectionless, peer-to-peer communication. It provides optional encryption via shared keys and supports unicase acknowledgements, but it does not implement full reliability (such as automatic retries or guaranteed delivery). 
 + 
 +ESP-NOWv1 supports payloads up to 250 bytes. In version 2 (unofficial community extension or modified firmware)payloads up to 1470 bytes may be supported, typically by layering on top of Wi-Fi frames. 
 + 
 +==== Wi-Fi ==== 
 + 
 +Wi-Fi is a wireless protocol defined by the IEEE in the 802.11 protocol standard. MOSH can use Wi-Fi as a transport, often over TCP or UDP sockets. This provides features like encryption (via TLS), reliable delivery (via TCP), and long-range routing. However, Wi-Fi is not required for a functional MOSH networks.
  
-==== WiFi ====+==== TTL Serial (UART) ====
  
-WiFi is a wireless protocol defined by the IEEE in the 802.11 protocol standard. And while MOSH can optionally use WiFi as a transport for MOSH messages, providing additional features, it is certainly not a requirement for a complete MOSH network.+TTL Serial (UART) is commonly used by MCUs for programming or debuggingbut it can also be used for MOSH communication between nodes. This is especially useful for bridging different transport -- for example, a MOSH Controller can connect a UART node to an ESP-NOW or Wi-Fi network, acting as a gateway.
  
-==== TTL Serial/UART ====+===== Transport Bridging =====
  
-Modern Microcontroller Units (MCU) commonly use TTL Serial/UART to communicate with host computer when initially programmedMOSH node can use this same transport to communicate with another MOSH node. Most commonlythis would be done on a MOSH Controller in order to bridge transports.+MOSH provides built-in method of bridging transports togetherThese bridges, called MOSH Controllers, act as relays or protocol translators. This allows multiple MOSH networks to communicate with one another, and allows a MOSH transports to be chosen based on specific use-cases.
/var/www/wiki.moshnetworks.com/data/attic/mosh/transports.1750866281.txt.gz · Last modified: by mosh

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki