near-real-time communication between an app in NY and an app in LA

[Alex Tweedly]

Josh Mellicker wrote:

> I type a number in a field on a card in LA
>
> A person in NY sees that number appear magically within seconds in  
> the corresponding field on their card
>
> How do it know?*
>
> I am compiling a list of ways for two apps to "sync up" by sending  
> simple packets of info to each other, through a central server:
>
> 1. socket communication a la Revchat
> 2. both apps updating and periodically checking a text file on the  
> server accessible through http
> 3. both apps updating and periodically checking the value of a record  
> in a MySQL database on the server
>
> The packets need to be stored in a MySQL database anyway, so I am  
> leaning towards MySQL for simplicity, but running the same query  
> every 3 seconds to see if a value has changed seems to be putting  
> undue wear and tear on the MySQL server.
>
> is checking a remote text file faster than running a MySQL query? It  
> seems like it would be.

I'd be tempted to use either (1) above, or perhaps a combination of (1) 
and (3).

Combination of 1 and 3:

Have a central server which is basically a very simple "echo" server; 
each client can talk to it and does so when it has done an update. It 
then tells all clients that there is updated info available, and they 
can retrieve it using MySQL.

So the socket part is very simple - open a socket to server, send a 
message after you have done the MySQL update, when you receive something 
from the server, do your MySQL query to see what has changed, or to get 
latest info. Since the messages have no complex content (almost no 
content at all), it couldn't be much easier.

But if the speed of update is important - and if there aren't too many 
fields that may change, it may be marginally faster to make the message 
be something like
  field name : new value
and have the echo server copy that out to each client.  You could then 
have the server do the MySQL update.

btw it also avoids an obscure possible problem with the "combination" 
scheme, since it ensures that all clients receive the updates in the 
same order and in the same controlled manner. The combo scheme may mean 
that client A gets a notification, retrieves update no 17 (say), then 
gets another notification and then retrieves update 18 - while client B 
gets a notification, retrieves updates 17 and 18, then gets another 
notification and retrieves no change.  Although MySQL ensures correct 
serialization, it doesn't ensure common "grouping" of updates into 
queries because of possible delays between initial notice and MySQL query.




-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.6.0/342 - Release Date: 17/05/2006