{"id":82,"date":"2026-02-05T11:35:42","date_gmt":"2026-02-05T11:35:42","guid":{"rendered":"https:\/\/www.myuremote.com\/website\/?page_id=82"},"modified":"2026-02-13T00:50:41","modified_gmt":"2026-02-13T00:50:41","slug":"concepts","status":"publish","type":"page","link":"https:\/\/www.myuremote.com\/website\/docs\/technical\/concepts\/","title":{"rendered":"Socket Handling"},"content":{"rendered":"\n
\n\n
\n

\n Concepts \u2013 MyURemote Core Gateway Architecture\n <\/h1>\n

\n This page is a technical reference that explains how MyURemote works internally.\n It is written for integrators, power users and developers who want to understand the design decisions\n and the execution model behind MyURemote\u2019s reliability across many brands and protocols.\n <\/p>\n

\n Key idea: MyURemote is not an app that calls APIs. MyURemote is<\/em> the API.<\/strong>\n <\/p>\n <\/header>\n\n

\n\n \n
\n

1. What MyURemote is in essence<\/h2>\n\n

\n MyURemote is a local socket gateway<\/strong> that turns a generic HTML\/JS user interface into a universal control system\n for embedded devices (TVs, receivers, streamers, extenders, IR\/serial gateways, etc.).\n <\/p>\n\n

\n The app receives requests from a WebView (HTML\/JS), translates them into byte-exact TCP communication<\/strong>\n (or other device-specific transports), and returns results to the UI through a strict, predictable response contract.\n <\/p>\n\n

\n This architecture is deliberately kept simple so the UI does not need to deal with:\n <\/p>\n

    \n
  • Firmware quirks and inconsistent protocol implementations<\/li>\n
  • Timing issues and missing EOF markers<\/li>\n
  • Devices that reply partially, slowly, or not at all<\/li>\n
  • Different communication stacks (TCP, HTTP, WebSockets, IR, Serial)<\/li>\n <\/ul>\n <\/section>\n\n
    \n\n \n
    \n

    2. The platform-independent core<\/h2>\n\n

    \n MyURemote runs on iOS and Android. The code is platform-specific, but the responsibilities are identical.\n The core is a three-part model:\n <\/p>\n\n

    2.1 Gateway \/ Handler (contract guardian)<\/h3>\n

    \n The Gateway\/Handler is the central coordinator between the frontend and the network layer.\n It is responsible for enforcing the MyURemote contract.\n <\/p>\n

      \n
    • Receiving HTTP\/JSONP requests from the WebView<\/li>\n
    • Parsing parameters and validating intent<\/li>\n
    • Determining whether a response is expected (based on callback<\/code>)<\/li>\n
    • Managing socket reuse (keepOpen<\/code>)<\/li>\n
    • Executing retry logic when needed<\/li>\n
    • Returning JSONP responses that the UI can interpret deterministically<\/li>\n <\/ul>\n

      \n In short: this layer is the contract guardian<\/strong>.\n <\/p>\n\n

      2.2 Socket Client (network reality layer)<\/h3>\n

      \n The Socket Client implements low-level TCP communication and tolerates real-world embedded device behaviour.\n It understands network reality, not UI assumptions.\n <\/p>\n

        \n
      • Connect to ip:port<\/code><\/li>\n
      • Write byte-exact data<\/li>\n
      • Read responses with real-world tolerance (no EOF, burst responses, partial data)<\/li>\n
      • Detect connect\/write\/read failures<\/li>\n
      • Support long-lived connections when keepOpen<\/code> is enabled<\/li>\n <\/ul>\n\n

        2.3 Response Synchronisation (determinism bridge)<\/h3>\n

        \n The UI request cycle is synchronous by nature (HTTP request \u2192 one response),\n while sockets are asynchronous and unpredictable. The Response Synchronisation layer bridges this gap.\n <\/p>\n