Difference between revisions of "VRET Archi"
(→Network Mechanism) |
|||
| Line 21: | Line 21: | ||
I discussed this issue with Ruud, Tim Verwaart, and a number of people in the computer graphics group. Our safest bet seems to be using the HTTP ports instead of just arbitrary sockets. | I discussed this issue with Ruud, Tim Verwaart, and a number of people in the computer graphics group. Our safest bet seems to be using the HTTP ports instead of just arbitrary sockets. | ||
| − | We have the following requirements | + | We have the following requirements for the connection |
* server (the side handling the call) needs to be notified when the network connection gets disabled. | * server (the side handling the call) needs to be notified when the network connection gets disabled. | ||
Revision as of 18:33, 11 August 2009
The goal of the system architecture is to provide an infrastructure for VRET related projects so that we
- provide the therapist with basic feedback like video, sound, heart rate
- provide programmers with a common approach and tools to handle remote therapy
- enable re-use of commonly required components
- easy switching between various therapies
The figure below shows the first proposal we arrived at after meeting with Willem-Paul, Niels, Christian, and Daniel.
Hardware
Check VRET_Hardware for details on the VR machine
Check Video_Hardware for details on the video streaming hardware
Network Mechanism
To handle communication between the patient monitoring system and the patient computers, we currently use plain sockets. While fast and simple, this requires all firewalls on the route between server and client to be open. Usually these ports will not be open except inside a single domain. Opening them will require negotiations with the network security staff and seems better avoided if possible.
I discussed this issue with Ruud, Tim Verwaart, and a number of people in the computer graphics group. Our safest bet seems to be using the HTTP ports instead of just arbitrary sockets.
We have the following requirements for the connection
- server (the side handling the call) needs to be notified when the network connection gets disabled.
One possibility is xml-rpc. A number of people in the graphics group working often with this do recommend xml-rpc. Maybe it's possible to replace the serve_forever() call with something else?
