Question related to the best practices/patterns of socket.
Scenario: Send command from the app to the device
Communication used: TCP/IP
What should be done when sending a command from app to device?
Is that necessary to open a new socket (with the last ip/port establish by the device) ~ which I think the answer is no
or
should I get access to the server - find the specific thread which has the socket open (at least ideally) and use that socket to request information? What probably I thought here is to have a docker-compose (with two dockers within) and communicate from the first docker (which will be basically an API controller with GET route) to the second docker (server that handle the socket connections).
Any tips would be welcome for the clarification on App -> Device socket command.
Related
I'm trying to build a web app that operates in real-time via a push model. I've used sockets in the past to achieve this, just not in a distributed service. My question is: Given that the host that receives the updated information (via Amazon
SQS) is not necessarily the host that the necessarily the host that
the web browser has a socket connection open with, How do we find the socket connection and then push the data.
Thanks
This might be a bit weird to explain, but I'll try my best.
I have a Lua program that's intended to serve some data through the network. Specifically, the internet. The data the program is actually transmitting are only strings stored within UDP packets. Generalized, this is how the program operates:
The first client launches the program and specifies that they are the 'host' of the connection. The program opens a connection on UDP port 6000 and the main loop listens for any packets received on said port.
The second client launches the program and specifies that they are to connect to the 'host' on port 6000. The user enters the IP, and the client opens a UDP connection using a random port between 6050 and 7000
When the client successfully connects to the server, they send a 'connection' packet, simply containing a '202 OK' string. The 'host' receives this and registers the new client
Now that the connection has been initialized, the programs can send data between each other using the registered data.
Now, on a local network this program works fine. The purpose of the 'host' mode is to have multiple clients connect to the host and have the host relay packets from one clients to all the currently registered clients. Port selections are arbitrary and random port selection from the client was simply to allow debugging and testing from a single computer. This has been tested between two and more computers on a physical network, and worked successfully. However, when I attempt to run this over the internet it's a no go. I know that the ports are closed and that's why it's not working. But seeing as I'm going to be distributing this program (privately) I can't expect every person to open ports on their router (or know how to). Security is not currently a concern with the program, and should be disregarded in the current state. That being said, I recognise there's the potential for a lot to go wrong with the use of this program through the network and I accept that. Onto the main question, how can I have the host and client communicate over the internet without having to open ports?
I'll elaborate - for example, browsers. Although the technology is quite different to what I'm doing, it's easier to paint a picture - the browser requests data from a web server, and it gets sent back to the client. But wait, if the router is in it's default state (I hope) all the ports are closed? So how does the client receive this data if the port is closed?
I hope this makes some kind of sense and I don't sound like a complete fool.
I managed to find some suitable libraries and utilities to be able to communicate through the internet (NAT traversal is now a term I am familiar with), those libraries being that supplied by NMAP. These libraries include an implementation for STUN in LUA, among HEAPS of other useful networking-related libraries and scripts.
To actually answer my own question (very simply), the clients and servers are behind what's known as a NAT gateway. Due to the limitations of addresses of IPv4, NAT gateways were implemented to bypass this limitation of IPv4 (a total of about 4.2 billion addresses) by separating the clients' internal network from the external network - in this case the internet. The NAT is supplied with a single IP address, and the NAT then supplies all of its users within the internal network with an IP respective to the network they're on. As such, the devices cannot directly be accessed without forwarding connections from the NAT gateway (generally the router) to the client. However, when using UDP connections the NAT gateway opens a port for the purposes of this connection which gets closed after the connection dies. This port that is opened differs from what is specified by the client when they open the connection, which is where the STUN methods come in. STUN allows the host to find the port that the client is connecting from and send data back to this port so the user can receive it. Bear in mind this is an EXTREMELY simple explanation of how the technology works, and I'd suggest reading up on the Wiki and some of the Request for Comments for STUN.
I am in the process of developing a peer to peer app,
I am a bit confused by the following scenario:
Lets say my application will use an outgoing port 1863 - which is also used for msn messenger(if this is not the port lets assume it is)
Now, client executes my app and connects to my server at port 1863.
I am a bit confused if this is going to produce any problems.
I know that 2 apps can use same port for outgoing communication. But what happens to the data coming back?
Also, does my client need to open port for my app to run correctly??
I know that 2 apps can use same port for outgoing communication. But
what happens to the data coming back?
That's exactly the problem the source port solves. The peer can always differentiate between 2 connections based on it. When it sends replies, what was the source port now becomes the destination port allowing the original receiver to correctly pass data to the rightful processes.
If you telnet to the ip address 192.43.244.18 port 13, you'll get the current time.
well, if I'm not wrong, this is simply a server socket. But there's one thing strange: how's this socket always listening?
If I take a PHP page and program sockets in there, I still have to request for the page first in order to activate the server socket, but this one isn't associated with any pages, and even if a make a perl script, I still have to request for that in order to run the server socket!
My question is: how can I make such a thing - an always listening socket - on a webhost (any language will do)?
You can run the process that's listening on the socket as a daemon (Linux) or service (Windows), or just a regular program really (although that's less elegant).
A simple place to begin would be http://docs.oracle.com/javase/tutorial/networking/sockets/clientServer.html which teaches you how to make a simple serversocket in Java that listens for a connection on a specific port. The program created will have to be run at all times to be able to accept the connections.
I have a simple node.js client and server programs running on one machine and when I try to connect to the server with second instance of client program simultaneously I get EADDRINUSE, Address already in use error. Is it possible to have two or more TCP based socket client connections (created with createConnection) to one server (created with createServer) on the same machine, or only one client program can be connected to the server at the same time?
Yes, it's possible. Infact, very common. Many applications open dozens, or hundreds of connections to the same server. It sounds like your client program is binding on a port. Only the server should be binding on a port. You should verify.
The client will usually use a random port between 1024-65535, as assigned by your OS. You don't need to worry about it. Since the client is initiating a connection to the server, the server port must unique to one program. Which is why your problem signifies you are trying to start the server twice. Please see http://www.tcpipguide.com/free/t_TCPIPClientEphemeralPortsandClientServerApplicatio.htm