server push to desktop client

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

server push to desktop client

Richard Gaskin via use-livecode
I need to make a desktop app (Mac only for now) that receives pushed
data from a LC server. I've never done this - all the desktop <-> server
interactions I've programmed have used the traditional client-server
model. So I'm looking for approaches/tips/ideas from anyone who has
experience with other approaches.

I'm not sure what protocol to use.

And maybe I'm making it too hard. Can FTP watch a server folder, and
detect and respond to the creation of a file in the folder? Maybe I
could use a method like that, if that's a capability of FTP.

Thanks for any input you may offer.

--
Phil Davis
503-307-4363


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: server push to desktop client

Richard Gaskin via use-livecode
Phil Davis wrote:

 > I need to make a desktop app (Mac only for now) that receives pushed
 > data from a LC server. I've never done this - all the desktop <->
 > server interactions I've programmed have used the traditional client-
 > server model. So I'm looking for approaches/tips/ideas from anyone
 > who has experience with other approaches.

I'd stick with simple polling for this.  Anything else requires either
opening a socket (with all the firewall/router changes needed to allow
that), or creating a dependency on a separate process like push
notifications, which would likely require LCB.

Polling can get the job done well enough, and is secure and requires no
router changes or external dependencies.  And if down the road you find
a convenient way to switch to something else you can change that part,
but at least it lets you get it out the door now using reliable features
and your existing skillset.


 > And maybe I'm making it too hard. Can FTP watch a server folder, and
 > detect and respond to the creation of a file in the folder? Maybe I
 > could use a method like that, if that's a capability of FTP.

You could poll from the client using FTP, but compared to HTTP it's a
noisy protocol, with many more steps internally.  The inefficiency of
FTP is more than offset by its utility when ad hoc access to remote file
stores are needed.  But when the goal is more specific, HTTP will often
beat it for both efficiency and client implementation cost every time.

On the server, an LC Server script that reports any changes to a folder
from the last time it was called would be straightforward to write, give
you reliably consistent results*, and would run quickly.


* Years ago when I was monitoring folders with FTP I learned more than I
cared to about FTP date representations.  They vary.  A lot.  By
different rules, according to a vastly flexible set of config options.
So you can never know which server will use month-and-day only up to a
certain cutoff, and then one of several month-day-year options for
anything older.  Sometimes the cuttoff is a month.  Sometimes it's the
year break.  Other times it's a specific number of days.  "Hey man, it's
all about flexibility!" In all cases it can mean a listing in which date
representations take on at least two different formats.

Even if you just had LC Server return "the detailed files" at least
you'd have solid consistency in the format of every file, every time.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: server push to desktop client

Richard Gaskin via use-livecode
In reply to this post by Richard Gaskin via use-livecode
Normal data flow is Mac app contacts a central server and sees if there is updated data to acquire. If yes, it acquires it.

This is the normal flow because of firewalls and ports.

For the server to really push data to a Mac client, the Mac client has to be a server, with a routable IP address / port. Most client machines are behind firewalls that allow them to initiate contact, but do not allow random external machines to contact them.

So the normal setup is, server has a dns entry on an IP address that anyone can reach from anywhere on the Internet. Server is listening on a single port for incoming connections.

Assuming the same data (updates) goes to each client, server has a text page containing a single integer. That integer is the number of the latest update. Client hits that web page periodically to see if its internal integer is different from the server. It’s a very quick exchange.

Client sees their internal integer isn’t the same. Let’s say client has 92 and server has 103.

Client then hits pages 93 to 103 to get all the updates. For example:

http://my.server.com/updates/93.txt
All the way to:
http://my.server.com/updates/103.txt

On the server side, you create update pages and increment the integer at something like:

http://my.server.com/updates/last.txt

The server is fast because it serves up static pages and the fastest page is last.txt because it’s only (in this example) three characters “103”.

I’m assuming all clients get the same data.

When each client gets unique data, you’ll probably have a database on the server and clients will do hits against the server to see if they have new data to gather, and if yes, they’ll do their query with their userid to gather their data.

 The trade off between server text pages and server database responses is one of those things you’ll need to figure out which is most efficient for you. Could be you ship a client that can do both and the very first hit to the server is a static page that tells the client “text” or “database” and then the client does the right thing. Could periodically check that page and perhaps you have a flag on it like “database always” that tells the client to stop checking, all updates forever will be the database update process.

But ... client pulls from the server because most servers cannot push through firewalls and routers an NAT servers to initiate first contact with a client.

Kee Nethery

> On Nov 4, 2019, at 11:26 PM, Phil Davis via use-livecode <[hidden email]> wrote:
>
> I need to make a desktop app (Mac only for now) that receives pushed data from a LC server. I've never done this - all the desktop <-> server interactions I've programmed have used the traditional client-server model. So I'm looking for approaches/tips/ideas from anyone who has experience with other approaches.
>
> I'm not sure what protocol to use.
>
> And maybe I'm making it too hard. Can FTP watch a server folder, and detect and respond to the creation of a file in the folder? Maybe I could use a method like that, if that's a capability of FTP.
>
> Thanks for any input you may offer.
>
> --
> Phil Davis
> 503-307-4363
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: server push to desktop client

Richard Gaskin via use-livecode
Thank you Kee! This is extremely helpful.
Phil


On 11/5/19 12:38 AM, Kee Nethery via use-livecode wrote:

> Normal data flow is Mac app contacts a central server and sees if there is updated data to acquire. If yes, it acquires it.
>
> This is the normal flow because of firewalls and ports.
>
> For the server to really push data to a Mac client, the Mac client has to be a server, with a routable IP address / port. Most client machines are behind firewalls that allow them to initiate contact, but do not allow random external machines to contact them.
>
> So the normal setup is, server has a dns entry on an IP address that anyone can reach from anywhere on the Internet. Server is listening on a single port for incoming connections.
>
> Assuming the same data (updates) goes to each client, server has a text page containing a single integer. That integer is the number of the latest update. Client hits that web page periodically to see if its internal integer is different from the server. It’s a very quick exchange.
>
> Client sees their internal integer isn’t the same. Let’s say client has 92 and server has 103.
>
> Client then hits pages 93 to 103 to get all the updates. For example:
>
> http://my.server.com/updates/93.txt
> All the way to:
> http://my.server.com/updates/103.txt
>
> On the server side, you create update pages and increment the integer at something like:
>
> http://my.server.com/updates/last.txt
>
> The server is fast because it serves up static pages and the fastest page is last.txt because it’s only (in this example) three characters “103”.
>
> I’m assuming all clients get the same data.
>
> When each client gets unique data, you’ll probably have a database on the server and clients will do hits against the server to see if they have new data to gather, and if yes, they’ll do their query with their userid to gather their data.
>
>   The trade off between server text pages and server database responses is one of those things you’ll need to figure out which is most efficient for you. Could be you ship a client that can do both and the very first hit to the server is a static page that tells the client “text” or “database” and then the client does the right thing. Could periodically check that page and perhaps you have a flag on it like “database always” that tells the client to stop checking, all updates forever will be the database update process.
>
> But ... client pulls from the server because most servers cannot push through firewalls and routers an NAT servers to initiate first contact with a client.
>
> Kee Nethery
>
>> On Nov 4, 2019, at 11:26 PM, Phil Davis via use-livecode <[hidden email]> wrote:
>>
>> I need to make a desktop app (Mac only for now) that receives pushed data from a LC server. I've never done this - all the desktop <-> server interactions I've programmed have used the traditional client-server model. So I'm looking for approaches/tips/ideas from anyone who has experience with other approaches.
>>
>> I'm not sure what protocol to use.
>>
>> And maybe I'm making it too hard. Can FTP watch a server folder, and detect and respond to the creation of a file in the folder? Maybe I could use a method like that, if that's a capability of FTP.
>>
>> Thanks for any input you may offer.
>>
>> --
>> Phil Davis
>> 503-307-4363
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

--
Phil Davis
503-307-4363


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: server push to desktop client

Richard Gaskin via use-livecode
In reply to this post by Richard Gaskin via use-livecode
Thanks for sharing your insight Richard. Great food for thought.

Phil


On 11/5/19 12:29 AM, Richard Gaskin via use-livecode wrote:

> Phil Davis wrote:
>
> > I need to make a desktop app (Mac only for now) that receives pushed
> > data from a LC server. I've never done this - all the desktop <->
> > server interactions I've programmed have used the traditional client-
> > server model. So I'm looking for approaches/tips/ideas from anyone
> > who has experience with other approaches.
>
> I'd stick with simple polling for this.  Anything else requires either
> opening a socket (with all the firewall/router changes needed to allow
> that), or creating a dependency on a separate process like push
> notifications, which would likely require LCB.
>
> Polling can get the job done well enough, and is secure and requires
> no router changes or external dependencies.  And if down the road you
> find a convenient way to switch to something else you can change that
> part, but at least it lets you get it out the door now using reliable
> features and your existing skillset.
>
>
> > And maybe I'm making it too hard. Can FTP watch a server folder, and
> > detect and respond to the creation of a file in the folder? Maybe I
> > could use a method like that, if that's a capability of FTP.
>
> You could poll from the client using FTP, but compared to HTTP it's a
> noisy protocol, with many more steps internally.  The inefficiency of
> FTP is more than offset by its utility when ad hoc access to remote
> file stores are needed.  But when the goal is more specific, HTTP will
> often beat it for both efficiency and client implementation cost every
> time.
>
> On the server, an LC Server script that reports any changes to a
> folder from the last time it was called would be straightforward to
> write, give you reliably consistent results*, and would run quickly.
>
>
> * Years ago when I was monitoring folders with FTP I learned more than
> I cared to about FTP date representations.  They vary.  A lot.  By
> different rules, according to a vastly flexible set of config options.
> So you can never know which server will use month-and-day only up to a
> certain cutoff, and then one of several month-day-year options for
> anything older.  Sometimes the cuttoff is a month.  Sometimes it's the
> year break.  Other times it's a specific number of days.  "Hey man,
> it's all about flexibility!" In all cases it can mean a listing in
> which date representations take on at least two different formats.
>
> Even if you just had LC Server return "the detailed files" at least
> you'd have solid consistency in the format of every file, every time.
>

--
Phil Davis
503-307-4363


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode