Difference between revisions of "Talk:Iron Curtain2"

From SlugWiki
Jump to: navigation, search
(UDP Discovery)
Line 7: Line 7:
  
 
==Reliable vs unreliable protocol ==
 
==Reliable vs unreliable protocol ==
If we use a reliable protocol we can implement extra commands for the server such as, shift colors, update, etc. That takes few bytes of instructions and could update 1000 times per second to make use of all the pixels on the screen.
+
If we use a reliable protocol we can implement extra commands for the server such as, shift colors, update, etc. That takes few bytes of instructions and could "update 1000" (limited by update rate of the pi) times per second to make use of all the pixels on the screen.
 
<br>
 
<br>
 
If we use unreliable protocols, we have to always output the whole screen to the server.
 
If we use unreliable protocols, we have to always output the whole screen to the server.

Revision as of 23:06, 23 December 2015

UDP Discovery

I can't make UDP discovery work reliably over wifi, even on a local machine. Instead of using UDP discovery it would probably be better to simply use a separate server as a discovery service, but not as a broker.

UDP vs TCP

The rate will likely be around 60 frames per second, in a local network, in the worst case. For our use case this means around 324Kb/s, which can be safely implemented as a TCP connection with a reliable protocol. If the latency proves to be problematic, we could use PUB/SUB from nanomsg .

Reliable vs unreliable protocol

If we use a reliable protocol we can implement extra commands for the server such as, shift colors, update, etc. That takes few bytes of instructions and could "update 1000" (limited by update rate of the pi) times per second to make use of all the pixels on the screen.
If we use unreliable protocols, we have to always output the whole screen to the server.