Thank you Alex,
I guess I have to admit here... as usual... being a generalist... I
have avoided a lot of the detail... so I don't know anything about
how to send and receive data over the internet. That is what I need
to know. The basics. The details of the basics. The rest, I will
fumble through. Lets assume I have an xtalk project running on a
server, and another clint project running on my machine. How do I
send a message to the server in such a way that it talks directly to
the xtalk server project? And the other way around?
Randall
On Dec 25, 2008, at 6:09 PM, Alex Tweedly wrote:
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
_______________________________________________
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
