I have a concox GT06 device from which I want to send tracking data to my AWS Server.
The coding protocol manual that comes with it only explains the data structure and protocol.
How does my server receive the GPS data collected by my tracker?
Verify if your server allows you to open sockets, which most low cost solutions do NOT allow for security reasons (i recommend using an Amazon EC2 virtual machine as your platform).
Choose a port on which your application will listen to incoming data, verify if it is open (if not open it) and code your application (i use C++) to listen to that port.
Compile and run your application on the server (and make sure that it stays alive).
Configure your tracker (usually by sending an sms to it) to send data to your server's IP and to the port which your application is listening to.
If you are, as i suspect you are, just beginning, consider that you will invest 2 to 3 weeks to develop this solution from scratch. You might also consider looking for a predeveloped tracking platform, which may or may not be acceptable in terms of data security.
You can find examples and tutorials online. I am usually very open with my coding and would gladly send a copy of the socket server, but, in this case, for security reasons, i cannot do so.
Instead of direct parsing of TCP or UDP packets you may use simplified solution putting in-between middleware backends specialized in data parsing e.g. flespi.
In such approach you may use HTTP REST API to fetch each new portion of data from trackers sent to you dedicated IP:port (called channel) or even send standardized commands with HTTP REST to connected devices.
At the same time it is possible to open MQTT connection using standard libraries and receive converted into JSON messages from devices as MQTT in real time, which is even better then REST due to almost zero latency.
If you are using python you may take a look at open-source flespi_receiver library. In this approach with 10 lines of code you may have on your EC2 whole parsed into JSON messages from Concox GT06.
Related
I want to simulate an UDP request-response application in ns3 by using 802.11n as communication technology, where a client/server A an access point AP and another server/client B exchange some messages (where each message has a particular size, i.e. 100, 130, 235 byte and so on):
*A* AP *B*
A------>AP
AP------>A
AP------>B
B------>AP
AP------>B
AP------>A
A------>B
B------->A
I followed this tutorial(https://www.nsnam.org/wiki/HOWTO_make_and_use_a_new_application) and I'm able to send and receive data with custom size but just for the first interaction. Furthermore I spent a lot of days to understand how can is possible modify the behavior of this application in order to simulate the aforementioned scenario. Are there any suggestions?
You don't need to create a new application. NS-3 already has applications that send traffic according to your specification (e.g. BulkSend Application, OnOff, and so on). Here's the link.
Regarding your application, it is very close to this same application using a client/server over wireless lan (link).
All you have to do is tweak the parameters. Let me know if you have any problems.
Is there any protocol, API or software in existence that can send data/IM/etc directly from one device to another with no server?
Can you not use HTTP GET/POST/DELETE directly between two devices when their device data is known to the user(s)?
I would very much like to know if there is ANY software/protocols that can do this.
thank you!
The internet is build on the Internet Protocol suite. This suite has 5 different layers of protocols: The physical layer, the link layer, the network layer, the transport layer and the application layer. Each depends on the one before.
If you just use the browser, by default HTTP (application layer) is used, which relies on TCP (transport layer), which relies on IP (v4 or v6, network layer), which relies on ethernet (link layer), which finally relies on the actual cable that's plugged into your computer (for WiFi, the first three are the same but the last two differ if I'm not mistaken).
Now to your question: Is there any protocol, API or software in existence that can send data/IM/etc directly from one device to another with no server?
Yes there is. I suggest you start looking at protocols that are in the application layer. To highlight a few standards next to HTTP(S): FTP is for file transfer, IMAP is for emails clients, SMTP is for email servers and SSH is a secure shell which can also be used to tunnel data through.
For your specific case, I think either FTP (FTPS if you want it over SSL), or SSH can be a solution, but it's hard to know for sure without the specifics.
The only thing that these protocols have in common is that one of the two computers will act like server and the other computer as client. This has as downside that port-forwarding might be necessary.
If you've chosen the protocol you'd like to use, then you're up for the next step, selecting a program that can do that for you. For HTTP(S), I'd recommend Apache. If you're using Linux and chose SSH, then you're in luck, there is a build in SSH server in Linux, you can use that. For other protocols, you might just want to search yourself, as I do not have any suggestions.
I hope this answers most of your questions!
Desirius
In browser context, WebRTC is probably what you are looking for: It allows user to user communications.
https://en.wikipedia.org/wiki/WebRTC
https://webrtc.org/
I have an API running on a server, which handle users connection and a messaging system.
Beside that, I launched a websocket on that same server, waiting for connections and stuff.
And let's say we can get access to this by an Android app.
I'm having troubles to figure out what I should do now, here are my thoughts:
1 - When a user connect to the app, the API connect to the websocket. We allow the Android app only to listen on this socket to get new messages. When the user want to answer, the Android app send a message to the API. The API writes itself the received message to the socket, which will be read back by the Android app used by another user.
This way, the API can store the message in database before writing it in the socket.
2- The API does not connect to the websocket in any way. The Android app listen and write to the websocket when needed, and should, when writing to the websocket, also send a request to the API so it can store the message in DB.
May be none of the above is correct, please let me know
EDIT
I already understood why I should use a websocket, seems like it's the best way to have this "real time" system (when getting a new message for example) instead of forcing the client to make an HTTP request every x seconds to check if there are new messages.
What I still don't understand, is how it is suppose to communicate with my database. Sorry if my example is not clear, but I'll try to keep going with it :
My messaging system need to store all messages in my API database, to have some kind of historic of the conversation.
But it seems like a websocket must be running separately from the API, I mean it's another program right? Because it's not for HTTP requests
So should the API also listen to this websocket to catch new messages and store them?
You really have not described what the requirements are for your application so it's hard for us to directly advise what your app should do. You really shouldn't start out your analysis by saying that you have a webSocket and you're trying to figure out what to do with it. Instead, lay out the requirements of your app and figure out what technology will best meet those requirements.
Since your requirements are not clear, I'll talk about what a webSocket is best used for and what more traditional http requests are best used for.
Here are some characteristics of a webSocket:
It's designed to be continuously connected over some longer duration of time (much longer than the duration of one exchange between client and server).
The connection is typically made from a client to a server.
Once the connection is established, then data can be sent in either direction from client to server or from server to client at any time. This is a huge difference from a typical http request where data can only be requested by the client - with an http request the server can not initiate the sending of data to the client.
A webSocket is not a request/response architecture by default. In fact to make it work like request/response requires building a layer on top of the webSocket protocol so you can tell which response goes with which request. http is natively request/response.
Because a webSocket is designed to be continuously connected (or at least connected for some duration of time), it works very well (and with lower overhead) for situations where there is frequent communication between the two endpoints. The connection is already established and data can just be sent without any connection establishment overhead. In addition, the overhead per message is typically smaller with a webSocket than with http.
So, here are a couple typical reasons why you might choose one over the other.
If you need to be able to send data from server to client without having the client regular poll for new data, then a webSocket is very well designed for that and http cannot do that.
If you are frequently sending lots of small bits of data (for example, a temperature probe sending the current temperature every 10 seconds), then a webSocket will incur less network and server overhead than initiating a new http request for every new piece of data.
If you don't have either of the above situations, then you may not have any real need for a webSocket and an http request/response model may just be simpler.
If you really need request/response where a specific response is tied to a specific request, then that is built into http and is not a built-in feature of webSockets.
You may also find these other posts useful:
What are the pitfalls of using Websockets in place of RESTful HTTP?
What's the difference between WebSocket and plain socket communication?
Push notification | is websocket mandatory?
How does WebSockets server architecture work?
Response to Your Edit
But it seems like a websocket must be running separately from the API,
I mean it's another program right? Because it's not for HTTP requests
The same process that supports your API can also be serving the webSocket connections. Thus, when you get incoming data on the webSocket, you can just write it directly to the database the same way the API would access the database. So, NO the webSocket server does not have to be a separate program or process.
So should the API also listen to this websocket to catch new messages
and store them?
No, I don't think so. Only one process can be listening to a set of incoming webSocket connections.
I'm evaluating some messaging libraries and protocols (e.g. ZeroMQ, WAMP). One of my main requirements is that sending messages from client to server and vice verse (two way communication) must be absolute safe with respect to client/server crashes. This means to me that e.g. the client must continue sending all not delivered messages after a spontaneous reboot. So the library should implement some kind of file based buffering. Is there anything there I can use out of the box?
[EDIT]
Some note on my use case:
In my scenario there are around 1000 clients communicating with one server. There is no direct client to client communication required. But I need a two-way communication, so both, the clients can push some data to the server and vice versa. The clients are connected via 3G mobile network. Both, client and server are written in C#. I focused on using ZeroMQ, Apache Thrift or WAMP. But one of the main requirements is to ensure asynchronous but safe messaging with respect to system crashes. So when the client starts an asynchronous data push to the server, and it will crash before the message can be delivered to the server, it is required that the client will continue sending the message after a reboot.
You might look into the Apache.org's Kafka project.
The problem is harder than it looks, and most people don't want to pay the price to make it happen.
Also, there is a UX issue with old queued up messages replaying without the user's understanding.
That is to say, if I have a server listening on 127.0.0.1, and a TCP connection comes in, how can I determine the process id of the client?
Also if there isn't an API for this, where would I be able to extract the information from in a more hackish manner?
(The purpose of this is to modify a local HTTP proxy server to accept or deny requests based on the requesting process.)
Edit: palacsint's answer below led me to find this answer to a similar question which is just what's needed
netstat -a -o
prints it. I suppose they are on the same machine becase you are listening on 127.0.0.1.
The only way to do this is if the connecting process sends some sort of custom headers which contains identifier. This is due to the fact that the networking layer is completely separated from the application layer (hint: OSI MODEL. This way it is possible to write lower layers software without caring what happens above as long as the messages exchanged (read: networking packets) follow a pre-determined format (read: use the same protocol).