nodemcu _ esp8266 server recieved data from android app and forward to esp8266 client - sockets

I am new programmer esp8266 with lua. I have 2 esp8266 and 1 android phone. One esp8266 is my server and another esp8266 is client. I want to send data from android app to server and server forward this data to esp8266 client. I programed server and client but i think it's wrong, the server received data from phone but not forward it to client.
The server listen on port 9000 and when received data forward it on the port 9999.and esp8266 client listen port 9999.
it is my esp8266 server code:
Can anyone help me?
wifi.setmode(wifi.SOFTAP)
wifi.ap.config({ssid="novin",pwd="12345678"})
print(wifi.ap.getip())
if sv~=nil then
sv:close()
end
function creat_server()
sv = net.createServer(net.TCP)
sv:listen(8080, function(c)
c:on("receive", function(c, pl)
if(pl~=nil) then
print(pl)
data=pl
pl=nil
end
end)
end)
if(data~=nil) then
sck(data)
data=nil
end
end
function sck(data)
sv:listen(9000,function(cc)
cc:send(data)
cc:on("receive", function(cc, dt)
print(dt)
data1=dt
end)
cc:on("sent",function(cc)
print("data send!!!!!!!!!!")
end)
end)
end
creat_server()

I saw your other question which was put on hold, your idea has a little bit problem. The esp which is server can't "Forward" data as you mean it, what I mean is that it can't be server and client at the same time, let it be server all the time. So let's review and recreate the scenario again:
You have android application which acts as a client and it will send some data to server node via POST method, there you get it and store it. you can then get the data on client node via GET method from previous server node. this is one way.
About the way you mentioned, first of all the ports in the code you have provided are different from what you have said in your question, other than that you need to first init node as SOFTAP and get the data and after that config it as STATION and send data via http module.
To simply put it, the code you have provided is too imperfect.
EDIT:
You can get all the docs and mini-examples you need from this site,
and in case you need http module, check out this part of that site.
Here's the doc indicating how to configure your wifi correctly according to your needs.
P.S. Http module has been added recently to the firmware, in case you want to use it and your IDE won't recognize it's syntax, use build cloud to build your own firmware, it will take only 5 minutes.
Also it was much easier for me to move forward with documents rather than example codes in the websites, it's up to you to chose which ever you want.

Related

ModbusTCP: Reverse engineering without having any documents of client(master)

Concept
we have a ship simulator(client) and Modbus controller(Server). Our goal is to develop an emulator(like controller) on my PC. But we have no information about the client(simulator).
Progress
Firstly we checked the actual outputs from the controller(server). There are 7 different variables like engine telegraph, rudder angle and so no.
Secondly, I checked the register numbers of the controller, which store command values. It was from 0 to 7.
Polling server with Modpoll software installed server:
I checked the register type. It was a holding register
I wrote a script to develop a Server like a controller with pymodbus Server. I can not only write specific values on the holding register from 0 to 7, but also there are proper handshake and responses to the simulator(client)
Problem
Client sends a request for reading with register numbers from 256. It means that my Server responds with zero values not with the command values written on the registers from 0 to 7. But the problem is that the simulator(client) shows the changes of the parameters on its Graphical user interface.
Screen shot from wireshark - it shows that clinet(simulator) sends a request with register nuumber from 246:
Client sends a request not only for reading but also for writing and the writing request overwrite the values written by Server (PC).
Question
how is it possible that the simulator receives the command signal by requesting different register numbers? client must send a request with register numbers from 0 to receive command signals.
I cannot understand why the client writes first before reading values from Server. This read request overwrites the values written by Server (pc). The Server (controller or pc) is to send a command signal to the simulator. I have no idea why the simulator first writes some values on sever and read it.
Please advise on this issue.
Best regards
Byeon seongsu.

Modbus client and server with message forwarding

I am working on a legacy modbus program for an industrial SCADA system.
Currently, the c++ program acts as both a modbus TCP server and client.
Client behaviour:
It reads from a number of vendor PLCs (servers) on site, performs calculations and sends control commands back to the PLCs based on the data received across the site.
Server behaviour:
responds to a variety of TCP read and write requests from web interfaces and laptops on site.
Until now, this has worked fine, but we have recently installed a logging client on the network which polls our program very frequently (sub-second) and this has revealed timing issues: the program can potentially take a very long time in its client loop performing calculations and reading PLC values before acting as a server and responding to incoming requests.
Easy solution would be to split the programs into a modbus server and client instance, and keep them both running on the same embedded PC.
The issue I have is that the remote web interface (HMI) must be able to control the behaviour of vendor PLC 2 and Vendor PLC 2 will only allow one TCP connection from the embedded PC. In the past the program has handled writes requests from the HMI by forwarding them on to the PLC 2 via the open socket.
I'd be keen to gather thoughts on best practices here.
My thinking:
the modbus server program will need to respond to the HMI requests and somehow store the information required for vendor PLC 2, and it will also need to set a status register to inform the modbus client that there is data for vendor PLC 2.
The modbus client program will need to read the status register (and data) from the server and pass this on to vendor PLC 2.
Am I heading in the right direction?
Without having details on your implementation I can only guess the problem is that your program is single-threaded, and delays are caused by waiting responses from PLCs.
So, if my assumption is correct, you need to switch to 'select' function and redesign your software to be totally async. You have to put all sockets (both connected and accepted) in a FDs set and wait events on them.
win32:
https://learn.microsoft.com/en-us/windows/desktop/api/winsock2/nf-winsock2-select
linux:
https://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=select&category=2
I've written the same app ages ago on win32 (but without calculations) and it easily processed about 200 PLCs, working on the same machine with SCADA.

low connectivity protocols or technologies

I'm trying to enhance a server-app-website architecture in reliability, another programmer has developed.
At the moment, android smartphones start a tcp connection to a server component to exchange data. The server takes the data, writes them into a DB and another user can have a look on the data through a website. The problem is that the smartphones very regularly are in locations where connectivity is really bad. The consequence is that the smartphones lose the tcp connection and it's hard to reconnect. Now my question is, if there are any protocols that are so lightweight or accomodating concerning bad connectivity that the data exchange could work better or more reliable.
For example, I was thinking about replacing the raw TCP interface with a RESTful API, but I don't really know how well REST works in this scenario, as I don't have any experience in this area.
Maybe useful to know for answering this question: The server component is programmed in c#. The connecting components are android smartphones.
Please understand that I dont add some code to this question, because in my opinion its just a theoretically question.
Thank you in advance !
REST runs over HTTP which runs over TCP so it would have the same issues with connectivity.
Moving up the stack to the application you could perhaps think in terms of 'interference'. I quite often have to use technical stuff in remote areas with limited reception and it reminds of trying to communicate in a storm. If you think about it, if you're trying to get someone to do something in a storm where they can hardly hear you and the words get blown away (dropped signal), you don't read them the manual on how to fix something, you shout key words such as 'handle', 'pull', 'pull', 'PULL', 'ok'. So the information reaches them in small bursts you can repeat (pull, what? pull, eh? PULL! oh righto!)
Can you redesign the communications between the android app and the server so the server can recognise key 'words' with corresponding data and build up the request over a period of time? If you consider idempotency, each burst of data would not alter the request if it has already been received (pull, PULL!) and over time the android app could send/receive smaller chunks of the request. If the signal stays up, just keep sending. If it goes down, note which parts of the request haven't been sent and retry them when the signal comes back.
So you're sending the request jigsaw-style but the server knows how to reassemble the pieces in the right order. A STOP word at the end tells the server ok this request is complete, go work on it. Until that word arrives the server can store the incomplete request or discard it if no more data comes in.
If the server respond to the first request chunk with an id, the app can use the id to get the response and keep trying until the full response comes back, at which point the server can remove the response from its jigsaw cache. A fair amount of work though.

websocket communication between clients in distributed system

I'm trying to build instant messaging app. Clients will not only send messages but also often send audios. And I've decided to use websocket connection to communicate with clients. It is fast and allows to send binary data.
The main idea is to receive from client1 message and notify about it client2. But here's the thing. My app will be running on GAE. And what if client1's socket is opened on server1 and client2's is opened on server2. This servers don't know about each others clients.
I have one idea how to solve it, but I am sure it is shitty way. I am going to use some sort of communication between servers(for example JMS or open another websocket connection between servers, doesn't matter right now).
But it surely will lead to a disaster. I can't even imagine how often those servers will speak to each other. For each message server1 should notify server2, server2 should notify client2. But things become even worse when serverN comes into play.
Another way I see this to work is Firebase. But it restricts message size to 4KB. So I can't send audios via it. As a solution I can notify client about new audio and he goes to my server for it.
Hope I clearly explained the problem. Does anyone know how to solve it? Or maybe there are another ways to build such apps?
If you are building a messaging cluster and expect communicating clients to connect to different instances of the server then server-server communication is inevitable. Usually it's not a problem though.
First, if you don't use any load balancing your clients will connect to the same server 50% of time on average (in case of 2 servers).
Second, intra-datacenter links are fast and free in all known public clouds.
Third, you can often do something smart on the frontend to make sure two likely to communicate clients connect to the same server. For instance direct all clients from the same country to the same server using DNS load balancing.
The second part of the question is about passing large media files. It's a common best practice to send it out of band - store on the server and only pass the reference to it. Like someone suggested in the comment, save the audio on the server and just send a message like "audio is available, fetch it from here ...". You don't need to poll the server for that. Just fetch it once when the receiving client requests it.
In general, it seems like you are trying to reinvent the wheel. Just use something off the shelf.
Let all client get connected to multiple servers and each server keeps this metadata
A centralized system like zookeeper stores active servers details
When a client c1 sends a message to client c2:
the message is received by a server (say s1, we can add a load balancer to distribute incoming requests)
s1 will broadcast this information to all other servers to get which server the client c2 is connected to OR a better approach to use consistent hashing which decides which server the client can connect to & in this approach message broadcast is not required
the corresponding server responses to server s1 (say s2)
now s1 sends the message m to s2 and server s2 to client c2
Cons of the above approach:
Each server will have a connection with the n-1 servers, creating a mesh topology
Centralized system (zookeeper) becomes a single point of failures (which is solvable)
Apps like Whatsapp, G-Talk uses XMPP and TCP/IP.

Idea about RESTful server

Ok, I had this argument with a friend about on how do we tackle data process in a restful environment.
The main idea is the application sends a data which is a position of the device (lat & long) to the server and expected to ping back the nearest device.
My argument was the process of determining the "nearest device" in the latlong position should be done in the server and just ping back the latlong of the nearest device.
Friend said that the process should be like this.. the server will pingback a json of every device with its latlong and the client itself will then determine the which one is the nearest.
Look at it this way:
A server is a datahub where all data is stored and processed.
A client is something that fetches data from a server, presents data to the user, and takes input from him.
Now you have to think about Seperation of Concerns. A client's job is to view data to a user, and take his input. A server's job is to process all data and transform it in such a way that a client needs to do minimal processing on it.
I.e. a client fetches some data from the server, all he should have to do now is show it on the screen. There should be minimal data processing on the client side. This is the server's job. The server's job is to make the client's job as easy as possible.
A client also has other things to do on the background (maybe also for other applications). It's CPU is not dedicated to your application, while your server's is.
What does a client need? The nearest device. What does the client ask the server? "Hey server, tell me what is the nearest device.". What should the server return? Exactly, the nearest device. Not a list of all devices which the client has to dig through himself.
No, I think that all information should be managed by the server...
If I understand you describe following schenario:
client sends it coords;
server send to client coords of any device
client receive data and compute nearest device
My questions is: why should a client compute the distance for anyone of (possible) thousands of devices?
Its elaboration power is not so high;
you consume most bandwidth
any information is already in charge of server
In my mind the best idea is a RESTful service where:
any client periodically sends its position (POST)
when a client need a certain number of neighbors then perform a request (GET)
server will contain most updated data, server compute distances, server create and send only small JSON as response.
This in my opinion. :)