Local communication through online application

I decided to post something simple after observing the comments. Now I can be more confident about which solution to present.

I always think of simple solutions so let's go for a really simple alternative.

The question here is how to make the online server send data to the server on an intranet.

If we focus on this logic without observing the real scenario, let's imagine inadequate and confusing solutions. Observing the scenario well, the server on the internet does not need to send the data to the printers. This can be done by the tablet that is on the server page.

I thought it would be confusing to explain without illustrations, so I did some doodling.

First let's give an overview on the scenario for better understanding:

Thecustomerplacesanorderandthewaiterentersthesystemthroughthetablet.

Whencomplete,theonlineserverreturnsapagewithahiddenformwithhiddenfields.

Theformactionwillpointtothelocalserveraddressontheintranet.

Inthisexample,apizzaisbeingordered.Thenintheformtheparameter"printer" with the value "pizza" will be specified.

<form action="http://192.168.1.50" method="POST">
<input type="hidden" name="printer" value="pizza">
<input type="hidden" name="data" value="os dados que deseja enviar para a impressora imprimir">
</form>

Note that the online server does not have access to the restaurant's local network, as this network is not open on the internet.

This communication is possible because the process takes place on client-side, through the brower of the client device, the browser of the tablet.

Technically, it is the tablet that is sending the request and not the online server.

You can also implement a function that sends the form via ajax if you want something more "refined", but it will not make any difference to the final result.

Thehiddenformmayhaveabuttonforthewaitertosendmanuallyoritcanbetriggeredautomatically.

Fromnowon,IbelievethatIdonotneedtogointodetailsbecausetheyareverysimplethings.

IftheserverisWindows,youcanusetheprinterfunctionsofPHP link

You can also implement communication with printers using sockets link

Simple like this, no fancy structures and monstrous costs. It's efficient and simple to maintain.

* Sorry for the exdrúxulos drawings.

If communication with the server is sporadic, and / or initiated by the user (for example, when clicking a refresh button), you should implement data fetching on the client using AJAX, in which case it is not meaningful communication SERVER < - CLIENT, but CUSTOMER > SERVER, however, with AJAX, it happens without reloading the page and the interface remains fully responsive.

If you need real-time communication, for example, to implement a chat, or a multi-user game, or an implementation of a collaborative interface, where different computer users participate on the same screen (and this is orchestrated by the server) , then it is best to use the new features for low latency communication between server / client.

Architecture for application with local and remote server

To have an application that has centralized local functions (printing) and also a remote server that stores the historical information, the product registers, etc. the ideal is to actually layer the application. Below is a proposed Android-based architecture, local ASP.NET Web server.API 2 / MVC 5, and remote server using Azure APP APIs with SQL Azure database (you can modify this architecture completely to use Amazon AWS, or even a server provisioned by you).

InthisarchitectureallthecomponentsofthelocalnetworksharethesameWiFi(orethernetnetworkinthecaseofthelocalserverthatmaybenexttotherouter).Theserverexposesawebserver(intheIIScaseofMicrosoft)withanAPIdevelopedinASP.NETWeb.API2.Thisserver,inturn,communicateswiththeremoteserverdeployingonMicrosoftAzurethatexposesanAPIthroughtheAzureAPPSAPI(whichmakesitmucheasiertomanageandcreateAPIs).Inordertobeabletoshareasmuchcodeaspossiblebetweenremoteserver,localandandroidapp,theandroidappcanbeprogrammedinXamarininC#inVisualStudio,allowingreuseofbusinessmodelanddatatransportclassesaswellasAPIclients,sinceeverythingwillbewritteninC#.XamarincreatesnativeAndroidapplications(iOSandWindowsPhone),sharingmorethan95%ofthecodebetweenthem.AppshavethesameperformanceasthosewritteninJavaonAndroidandObjective-ConiOS,astheyarecompilednativelyattheendoftheprocess,ordynamicallyintheandroidvirtualmachine.

WEBapplicationcommunicationwithservers

Theimplementationofwebcommunicationwithserverscanbedoneinseveralways.Belowarethemostcommon.

ThedefactooptionisWebSockets.

AtutorialinPortuguese: link

For PHP, a library: link

Official documentation: link

Notes

However, even a chat client, or a collaborative application, can work with pure AJAX and polling operations (the client queries the server, for example, every 30 seconds for new data). That's how things were done in the recent past.

Implementing real-time communication is not something simple. Usually beginners make so many mistakes that they give up and a polling implementation with AJAX might be simpler to start.

However, an application with low latency data refresh is a wonder to the end user, but it also generates a lot of pride in who built it.

There are also options for WebSockets, and abstraction layers on top of them too (which can gracefully decay for polling or other simpler mechanism in browsers that do not support websockets, for example).

Considering that the main difference between the hosting server and your local server is the fact that one is online and the other is not, mainly due to your modem acting as a firewall, we can say that the basic solution would be: p>

• Perform port redirection on your modem so that you can access your local server over the internet (see Port Forwarding );

• Configure your online (hosted) application to consume a service or url through the CURL library.

  $curl = curl_init();
  curl_setopt($curl, CURLOPT_URL, "http://seuip:8080/teste.php");
  curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
  curl_setopt($curl, CURLOPT_HEADER, false);
  $response = curl_exec($curl);
  var_dump($response);
  

But be careful .. I guess this is just a joke. Well, do not see any reason in this world that justifies exposing your local server on the network.