This is just "polling" logic and won't work for us, which is why I am asking 
about web sockets.

In our world, when a machine goes down we have to immediately contact the 
browser managing the machine.  In polling logic, it would mean we only check 
every X interval.  Before anyone says "well just make it a short interval" take 
into account I may have 50 - 100 browsers all polling continuously.  This is a 
lot of traffic which simply asks the server "anything for me".  Keep in mind 
99% of the time the answer from the server will be no.  This is a lot of 
overhead for the 4D Server to be dealing with continually.

It's much more efficient, considerably less taxing, to just have the server 
push a request to the shop floor browser only when some action is required...



  Stephen J. Orth                                                
  The Aquila Group, Inc.          Office:  (608) 834-9213
  P.O. Box 690                           Mobile:  (608) 347-6447
  Sun Prairie, WI 53590


-----Original Message-----
From: 4D_Tech <> On Behalf Of John DeSoi via 4D_Tech
Sent: Tuesday, January 15, 2019 3:31 PM
To: 4D iNug Technical <>
Cc: John DeSoi <>
Subject: Re: Socket Communication


> On Jan 15, 2019, at 3:08 PM, Stephen J. Orth <> 
> wrote:
> Not sure I understand what you are saying, would you be able to provide me 
> with a high level overview of what you are thinking?

HTTP is a request/response protocol where the server only responds to requests 
from the client. Websockets are full duplex and bi-directional meaning either 
side of the connection can both send and receive asynchronously. See

> Our Server will be performing analytics' and at some point it will trap on a 
> condition that needs to be communicated to the shop floor.  For example, a 
> machine has been idle for more than 5 minutes.
> When this event is flagged, the server needs to tell the browser on the 
> floor, associated with this machine, to take a specific action. Basically the 
> browser will need to present a different window for the operator to respond 
> into.
> So I'm just trying to understand how the HTTP idea you presented would work 
> in this situation...

This can be achieved in a HTTP/browser interface without much trouble. I think 
all you would need to do is set a timer for your web interface to periodically 
check with the server for a change in state. Probably not as efficient as 
websockets, but a fraction of the development effort unless you already have a 
websocket server implementation ready to go.

Here is an example of using a JavaScript timer to perform some action, e.g. a 
periodic http call to your server.

John DeSoi, Ph.D.
4D Internet Users Group (4D iNUG)

4D Internet Users Group (4D iNUG)

Reply via email to