VRET Archi - Revision history

Wouter: /* Network Mechanism */

2010-08-02T07:00:38Z

‎Network Mechanism

Wouter: /* Network Mechanism */

2010-08-02T07:00:17Z

‎Network Mechanism

Wouter: /* Database */

2009-12-10T09:39:35Z

‎Database

Wouter: /* Download */

2009-12-10T08:46:46Z

‎Download

Niels at 13:37, 4 December 2009

2009-12-04T13:37:51Z

Wouter at 11:38, 20 August 2009

2009-08-20T11:38:21Z

Wouter at 11:36, 20 August 2009

2009-08-20T11:36:16Z

Wouter at 11:34, 20 August 2009

2009-08-20T11:34:38Z

Wouter at 11:34, 20 August 2009

2009-08-20T11:34:21Z

Wouter: /* Network Mechanism */

2009-08-12T15:19:10Z

‎Network Mechanism

@@ Line 26: / Line 26: @@
 == Network Mechanism ==
-To handle communication between the patient monitoring system and the patient computers, we currently use XML-RPC [http://www.xmlrpc.com xml-rpc] which runs on sockets. While reasonably 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.
+To handle communication between the patient monitoring system and the patient computers, we currently use  [http://www.xmlrpc.com XML-RPC] which runs on sockets. While reasonably 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.

@@ Line 26: / Line 26: @@
 == 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.
+To handle communication between the patient monitoring system and the patient computers, we currently use XML-RPC [http://www.xmlrpc.com xml-rpc] which runs on sockets. While reasonably 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.
@@ Line 32: / Line 32: @@
 We have the following requirements for the connection
 * server (the side handling the call) needs to be notified  when the network connection gets disabled.
-* some people in the project asked if it's possible to call functions directly instead of building large <code>if(received="commandX") then ....</code> loops. RPC would enable somethign like that. That will mostly replace the if-then constructs with "def commandX()" constructs so I do not belief that it will save much space.
+* some people in the project asked if it's possible to call functions directly instead of building large <code>if(received="commandX") then ....</code> loops. RPC enables this. This way we avoid if-then constructs with "def commandX()" constructs.
-* Support for "channel coding": putting objects into the stream and re-building an object out of it at the other end of the channel. In Java this is trivial by extending "serializable" but in Python apparently it is not. An XML library is just one of many solutions for that. XML blows up data easily by a factor 6 and requires extra parsing causing an order of magnitude slowdown [ [[Image:Xmlrpc-perf.pdf]] ]). For small transactions there is not much difference and in our case XML seems acceptable as transfer format.
+* Support for "channel coding": putting objects into the stream and re-building an object out of it at the other end of the channel. In Java this is trivial by extending "serializable" but in Python apparently it is not. XML-RPC handles all this for us.
 * Many python RPC servers on a single computer have to be able to use the same port at the same time. So the addressing seems to require more than just the computer name and port number.
-One possibility is [http://www.xmlrpc.com 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? Being notified of disconnection seems possible: [[http://xmlrpc-c.sourceforge.net/doc/libxmlrpc_server_pstream++.html | usermanual XML-RPC]]
+Minus points:

← Older revision		Revision as of 09:39, 10 December 2009
Line 110:		Line 110:

	[[Image:Database_archi.png]]		[[Image:Database_archi.png]]
		+
		+	The database is not the SVN server. That is because the SVN server is ment to store all project information. I suppose we do not want therapists to get access to that.

@@ Line 11: / Line 11: @@
 == Download ==
-zip file containing architecture can be downloaded [[Image:Src_20aug09.zip]]
+Resources are on SVN: [https://mmi.tudelft.nl/cgi-bin/vret_oud.cgi/browser/Tools Svn tools].
 == Therapist Interface ==

← Older revision		Revision as of 13:37, 4 December 2009
Line 14:		Line 14:
	Note, this is a beta version with nothing but a working first version NetworkTools and Database, a very simple Scaredness analyser and a few widgets for the therapist to communicate with the scaredness analyser. It is recommended to not yet use this and wait till a first word has been implemented on top of this architecture (work currently in progress together with Niels)		Note, this is a beta version with nothing but a working first version NetworkTools and Database, a very simple Scaredness analyser and a few widgets for the therapist to communicate with the scaredness analyser. It is recommended to not yet use this and wait till a first word has been implemented on top of this architecture (work currently in progress together with Niels)

		+	== Therapist Interface ==
		+	[[Therapist Interface discussion]]

	== Hardware ==		== Hardware ==

@@ Line 12: / Line 12: @@
 == Download ==
 zip file containing architecture can be downloaded [[Image:Src_20aug09.zip]]
-Note, this is a beta version with nothing but a working first version NetworkTools and Database, a very simple Scaredness analyser and a few widgets for the therapist to communicate with the scaredness analyser.
+Note, this is a beta version with nothing but a working first version NetworkTools and Database, a very simple Scaredness analyser and a few widgets for the therapist to communicate with the scaredness analyser. It is recommended to not yet use this and wait till a first word has been implemented on top of this architecture (work currently in progress together with Niels)

← Older revision		Revision as of 11:36, 20 August 2009
Line 11:		Line 11:

	== Download ==		== Download ==
−	zip file containing architecture can be downloaded [[Image:Src_20aug09.zip~~\|here~~]]	+	zip file containing architecture can be downloaded [[Image:Src_20aug09.zip]]
		+	Note, this is a beta version with nothing but a working first version NetworkTools and Database, a very simple Scaredness analyser and a few widgets for the therapist to communicate with the scaredness analyser.

← Older revision		Revision as of 11:34, 20 August 2009
Line 11:		Line 11:

	== Download ==		== Download ==
−	zip file containing architecture can be downloaded [[Image:Src_20aug09.zip here]]	+	zip file containing architecture can be downloaded [[Image:Src_20aug09.zip\|here]]

← Older revision		Revision as of 11:34, 20 August 2009
Line 9:		Line 9:
	In the below sections we discuss the VRET hardware and network mechanism, and the modules shown in the figure. The colors in the picture match components in Therapist and Patient system to parts in the Database.		In the below sections we discuss the VRET hardware and network mechanism, and the modules shown in the figure. The colors in the picture match components in Therapist and Patient system to parts in the Database.
	[[Image:Vret_archi.png\|thumb\|500px]]		[[Image:Vret_archi.png\|thumb\|500px]]
		+
		+	== Download ==
		+	zip file containing architecture can be downloaded [[Image:Src_20aug09.zip here]]

← Older revision		Revision as of 15:19, 12 August 2009
Line 31:		Line 31:
	* Many python RPC servers on a single computer have to be able to use the same port at the same time. So the addressing seems to require more than just the computer name and port number.		* Many python RPC servers on a single computer have to be able to use the same port at the same time. So the addressing seems to require more than just the computer name and port number.

−	One possibility is [http://www.xmlrpc.com 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? Being notified of disconnection seems possible: [[http://xmlrpc-c.sourceforge.net/doc/libxmlrpc_server_pstream++.html\|usermanual XML-RPC]]	+	One possibility is [http://www.xmlrpc.com 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? Being notified of disconnection seems possible: [[http://xmlrpc-c.sourceforge.net/doc/libxmlrpc_server_pstream++.html \| usermanual XML-RPC]]