Andre's post: Rev and the Web...

[Alex Tweedly]

Randall Lee Reetz wrote:
> Andre,
>
> I have a need for ongoing conversion of xTalk projects/stacks to 
> multiple-simultaneous-user collaborative environment (projects running 
> over the web?).
>
> I found your post "Rev and the Web, feedback wanted." and want to 
> revisit these concepts to see what has been done and what could be 
> done quickly.
I should preface my reply by saying that I haven't read Andre's post for 
quite a long time, so I am replying *just* to the questions raised here, 
not properly in the context of Andre's earlier email.
>
> Lets agree for now to go with your "helicopters on the bottom of the 
> ocean" approach.  As I understand it, you suggest a Rev developer 
> would provide links to projects/stacks which the user would download 
> along with the appropriate Rev runtime player app.
>
> That is all well and good.  But then what.  What I then need is some 
> way to keep track of real time multi-player interaction (some way to 
> send data upstream to a server, have that data processed, send 
> response data downstream to each applicable client (user).  The same 
> problem might be solved as a pure peer-to-peer (no central servers 
> involved) topology... theoretically elegant, almost impossible in 
> practice.
>
First thing you need to consider is what you man by 'real time' and by 
'multi-player'; i.e. do you have strict timeliness requirements (and if 
data cannot be deliverd in time, it should be dropped rather than 
causing a delay for any other data) and how many users are we talking 
about simultaneously.
> So, I guess I need some simple advise on how to set up a central 
> server running Rev and accepting input from web connections to users, 
> and how the user's projects would best package data, send it upstream 
> to the server stack and how to for each client stack to listen in to 
> the server and accept server processed data.
>
" ... from web connections ..." ?   Do you really mean 'web connections' 
or rather 'internet connections' (or even network connections) ? To me 
(old-fashioned ?). 'web connections' means you are already implying HTTP 
/ HTML connections - but I suspect from the later questions that you 
mean 'internet connections'.
> I need to understand how to send and receive data over the web to 
> servers and other clients in real time (from Rev projects).
>
> 1. How to set up a connection.
> 2. How best to keep track of users (clients) along with session 
> specific connection address data.
> 3. How to protect data and transmission.
> 4. How to pack data and send to server or to clients (protocol and 
> standards and handshakes, etc.)
> 5. How to verify transmission.
>
The short answer is probably to look at Bjornke's RevChat applications 
(he has both client and server) at 
http://bjoernke.com/runrev/chatrev.php    That has mature server that 
handles connection setup, tracking clients, data replication, etc.

A longer answer would say things like....

Easiest way to handle connection setup is to have a single central 
server; any client connects to it and is then (potentially) redirected 
to a diferent server or servers for data transmission and/or reception.

How may simltaneous connections need to be handled ?  How much data will 
be expected ? How hard are the 'real-time' requirements ?   If the 
number of receiving clients is small-ish (and./or) the data rate is 
small enough - then replicate all data at the server, sending it all out 
a connection to each client. (this is the place to think about worst 
case data rate, and see what impact you mght get from transmission delay 
at the server).

'protect data and transmission'   Protect in what sense ?  To make sure 
it happens ? - either use TCP or a TCP-based protocol (assuming you can 
afford the lack of real-time characteristics implied),   To ensure data 
is uncorrupted ? - either use TCP or UDP and a app-level checksum.  
Protect from prying eyes - either use ssl or similar, or add app-level 
encryption (and pass keys off-channel).

pack data ?   A very broad question ... depends on so many variables I'm 
not sure I'd know where to start. Look at the (likely) context - do 
users really need to be Basic Broadband (or better) right away to avoid 
Christmas Day mayhem. If so, it is likely you should avoid optimizing 
transmissin charecteristics, and focus on minimal client CPU overhead,

And lots more questions (if it  wasn't already very late Christmas 
evening ....)

-- Alex