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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
