# Architectural guidance around UAVCAN Gateway **URL:** \ **Category:** Applications & Usage\ **Created:** [February 27, 2020, 10:43am UTC](https://forum.opencyphal.org/t/architectural-guidance-around-uavcan-gateway/769 "2020-02-27T10:43:50Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [February 28, 2020, 3:40pm UTC](https://forum.opencyphal.org/t/architectural-guidance-around-uavcan-gateway/769/4 "2020-02-28T15:40:43Z")
Okay, thanks for the clarifications. For a more constructive discussion we are going to need to know what the transport reliability requirements are and what are the failure modes. What could cause an Ethernet frame to be lost in your setting? For example, is the cable routed through a factory floor with welding equipment generating nanosecond disturbances, etc. Is your bandwidth budget tight? Can you please read this and see if the approach is applicable in your case: [Idempotent interfaces and deterministic data loss mitigation](https://forum.opencyphal.org/t/idempotent-interfaces-and-deterministic-data-loss-mitigation/643) > Are you suggesting that I have two UAVCAN stacks in the Gateway; downstream one with CAN and upstream one with UDP? Yes, this is exactly what I am suggesting. This can be implemented trivially using PyUAVCAN. Actually, I am probably going to draft up a simple demo tomorrow or the day after for demonstrational purposes; I expect it’s going to be a hundred lines of Python or so. > do you foresee any complication with a unified DSDL No. > Node Addressing There are two obvious solutions: a transparent bridge and a facade. The former is assumed to expose the CAN nodes below the _Gateway_ as if they were on the same logical network with _Message Broker_. The latter renders _Gateway_ a dedicated node which hides the topology of the underlying network from the _Message Broker_; e.g., if _Board1_ publishes a UAVCAN message, the _Gateway_ forwards it over to the _Message Broker_, and the latter sees it as if the message was published by _Gateway_ itself. Both Bridge- and Facade-based approaches are possible; the former is very low level (requires dealing with the network at the transfer level), the latter is high level (operating on messages and service calls). The optimal approach depends on the requirements of your application. > timing? There is not enough data to provide a meaningful response. To answer broadly, UAVCAN is simple and a single human can effortlessly place the entire stack into one’s imagination, so at the protocol level the temporal properties are evident. Translating a message from one network into another amounts to receiving frames at one end (e.g., CAN frames) and emitting equivalent frames at the other end (e.g., UDP packets). --- _[View the full topic](https://forum.opencyphal.org/t/architectural-guidance-around-uavcan-gateway/769)._