I need to develop an app in ionic that uses TCP connection in order to send and receive data. So there is a library socket.io, I used this library, but the problem is I want to communicate the app sends data from phone to an Arduino device. After a search I think this is not possible with socket.io because it should work in a browser at the client side.
Is there another library for TCP to send and receive data from phone to Arduino or vice versa?
Related
Is it possible to communicate between two mobile devices without the need for an intermediary server?
For example: An app that sends a message to another device via its external IP address.
It would be necessary for the device to be both client and server at the same time,
it is possible?
Can you explain how to make connection between Hbbtv React App in TV and mobile App in React Native?
I implement SSDP Client in React Native Mobile App to look for SSDP Server (That should be implmented on TV). Then receiving IP Address of that Server (Like in DIAL Architecture). Server also creating WebSocket Server. This server should start Hbbtv App that is written in React.js.
Now I can send messages from Mobile App to Hbbtv React App through this server, but I have no idea how to implement this kind of SSDP+WebSocket server on my TV.
This project https://github.com/fraunhoferfokus/cordova-plugin-hbbtv provides a good example and may answer your question. It is a cordova plugin for Android, but gives you an overview how to implement the Client for framework like React Native. The Hello World Mobile application in https://github.com/fraunhoferfokus/cordova-plugin-hbbtv-helloapp/ provides an example to use the plugin to discover and launch on TV.
The HbbTV App is developed using Web Technologies like in your case React.js and uses WebSocket to establish a connection to the local WebSocket Server running on the HbbTV Terminal. This folder https://github.com/fraunhoferfokus/cordova-plugin-hbbtv-helloapp/tree/master/www provides an example of a simple HbbTV App using CS Features. You can take it as a reference for your react.js. The main file you need to follow is https://github.com/fraunhoferfokus/cordova-plugin-hbbtv-helloapp/blob/master/www/js/cs-app.js. I hope this help.
For successful communication, the Companion Screen application should be on the same home network as the HbbTV terminal (TV Set).
The terminal (TV Set) implements the server providing endpoints that provide the server-side of the Websocket protocol for clients (HbbTV® application on the terminal and Companion Screen application).
The server shall be able to accept connections once an HbbTV® application on the terminal (TV Set) has called the getApp2AppLocalBaseURL() method of the HbbTVCSManager embedded object and until the application exits. Please see:
https://developer.hbbtv.org/references/apis/defined-javascript-apis/companion-screen-discovery-apis/
The terminal (TV Set) handles connection requests from clients (HbbTV® application and Companion Screen application) in the manner defined in clause 14.5.3 of the ETSI TS 102 796 standard and applies pairing rules defined in clause 14.5.4 of the ETSI TS 102 796 standard to determine whether to pair connections from two clients. It then acts as a relay, as defined in clause 14.5.5 of the ETSI TS 102 796 standard in order to relay messages between the two client connections that are paired.
In a nutshell, the HbbTV® application on the terminal (TV Set) connects to the server on the terminal (TV Set) and the connection enters a waiting state.
At this point, the Companion Screen application should connect to the server on the terminal and the connection enters a waiting state.
The terminal (TV Set) shall pair two waiting connections according to the following rules:
One waiting connection shall be on the local service endpoint (and
therefore be inferred to have come from the HbbTV® application
client).
One other waiting connection shall be on the remote service
endpoint (and therefore be inferred to have come from a remote
client, such as a Companion Screen application).
The app-endpoint portion of the resource name used in the client handshake request shall match between both waiting connections.
This "tactic" should give you the desired result.
Currently, I am using Raspberry Pi on which I am hosting mosquitto MQTT broker and a separate C application that connects and subscribes to localhost. It is a wrapper of what I actually needed.
I actually need an MQTT broker running inside a C application from where I can control what client IDs can connect. Is there any way to achieve it?
Mosquitto provides a plugin interface that allows you to control which clients can connect and which topics they can publish/subscribe to.
Normally you would not control access by client id as this can be easily spoofed, instead you should probably be using username/password (or client certificates) to identify the clients.
There are example plugins that store this information in a database so it can be updated dynamically
Do you happen to know common application using unix socket api doesn't work on computer connected to internet router? For example, assume that there is a computer that is running a simple web server using socket in C. when a web browser in another remoter computer send a request, the web server cannot send a response to the request since its port is closed by the internet router(?) (Of course, there might exist another reasons).
However, the common applications by a competent developers works well. For example, utorrent client receives a request for some data from peers and responds to the request well, although a computer that is running utorrent is connected to the internet router. Does utorrent adjust router configurations using some system calls? If not, how does it upload the some data?
So my question is that
how does common application using socket API accomplish to forward its port, with the connection to the internet router?
How my program in C accomplish to forward its port with computer connected to the internet router?
Thank you in advance.
If you're connected the internet through a NAT router, in most cases any unsolicited connection into the router from the WAN will be refused. What you need is to tell the router (in some way) that unsolicited traffic coming in on a specific port number or range is to be accepted, and forwarded on towards a specific local IP address. This can either be done manually in your router's configuration, or if your router supports UPnP you can use that protocol to configure port mapping for the traversal of the router.
They don't. To send and receive data on the connections your program has started it's not needed. Port forwarding needs to be done by hand by the machine administrator and is only required to receive new connections.
Is is must to have the client to be browser for a web server? Is this a good architecture for mobile clients to have some non browser client and get data from webservers?
I am thinking of implementing a basic browser at mobile client. Login using web methos and rest of the communication (monitoring info at every 10sec) be done using web sockets. Will this work?
Can I implement web sockets without JS?
Thanks
You can implement WebSockets outside the browser, and without any JavaScript involved. You could have i.e. a Android native Java application that talks to a server over WebSockets.
WebSockets is a protocol. The WebSockets API defined for JavaScript running in the browser is something different.
You can authenticate a WebSockets connection during the WebSockets handshake using any method available with HTTP (i.e. basic auth, digest, cram-md5, client cert.-based (TLS), and so on), since the WebSockets handshake is still like any other HTTP conversation. It is only after the handshake is completed that WS is different from HTTP.
Note, that what you likely want on the server side is not a plain old Web server, but a WebSockets server/framework.
Whether using WS to connect mobile clients is "a good architecture" is a bit vague. I would say: if you decide to have your mobile client talk to a server, and that server is under your control, and you want to leverage WS advantages like near real-time/bidirectional, then it might be good. Better than cooking your own low-level protocol.