Skip to content

Networking Assumptions

martinmcclure edited this page Jun 3, 2020 · 2 revisions

These are the set of assumptions RSR makes about networking.

  • TCP is reliable enough
  • Bandwidth limits will exceed the needs of applications
  • Latency will be that typical of terrestrial network links, less than 500ms round trip time

These assumptions will not always be true, but they will hold most of the time, and greatly reduce the complexity needed in the framework.

Discussion of these assumptions and their limitations:

TCP is reliable enough

TCP is designed as a "reliable" service, with error checks, re-transmission of dropped or mangled packets, and so on. Still, in the real world connections do sometimes hang and ultimately drop. When a new RSR connection is made for the purpose of replacing one that has dropped, the domain objects that the previous connection was working with may have survived, but the service objects need re-building. It would be possible to design an application such that some service objects also survive, but that would require a least a little more framework support than is currently planned.

Bandwidth limits will exceed the needs of applications

The widespread availability of high-speed connections, even for mobile devices, has removed many concerns about bandwidth usage. It would be possible to base an RSR connection on a compressed stream based on a TCP connection, but that may not be needed.

Latency will be that typical of terrestrial network links, less than 500ms round trip time

RSR is, at least initially, designed for interactive "human-time" use. Benchmarks for decent interactivity range from "Pauses of under 10ms are not detectable" to "Any wait over two seconds is too long." Links based on the global fiber network are usually under 500ms round trip time. Links through geostationary satellites are longer, and any communication over even longer distances (the Moon, Mars) makes traditional human-interactive architectures impractical.

With high bandwidth widely available, RSR doesn't have to worry too much about the amount of data sent and received in an interaction, but it does have to worry about latency. RSR's design is intended to make it easy for interactive applications to function with a minimal number of network round trips.