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

[Randall Lee Reetz]

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