I have a GPS tracker that communicates with TCP protocol. The data will be send to web client via Websocket. I also need to persist it to database.
I intent to use Django as my main framework for this. But the problem is the TCP protocol.
Can django channel listen to TCP/UDP protocol?? Or should I use asyncio and then send it to django channels applications via ASGI??
Related
I have IoT devices which are rfıd readers. This devices send stream data with HTTP Post message. I use Django to get data from these devices. While receiving this data, I can write a function to get data from post requests coming directly with Django and receive the data from the request in this function with Django REST Framework or I can listen with a TCP Server socket. Which of these two approaches is more suitable for retrieving data? Because when I use a TCP Server socket, Django REST Framework does not work for HTTP requests, only the TCP socket works.
I'm trying to use them for the first time and wonder I'm headed to the right direction.
Here are my understandings,
socket.io is a wrapper around websocket, and falls back to sub-optimal solutions when websocket is not available.
Django channels can talk websocket as well.
(I think it converts django as a message queue like system. although this understanding or misunderstanding should affect this question)
So I'm trying to use Django channels on the server and socket.io-client on the client.
socket.io has api which looks like
socket.on(type, (payload)=> {})
Whereas Django channels has a form of
message.reply_channel.send({
"text": json
})
is the "text" type of socket.on(type)?
Can Django channels and socket.io-client talk to each other?
From the Socket.IO README:
Note: Socket.IO is not a WebSocket implementation. Although Socket.IO indeed uses WebSocket as a transport when possible, it adds some metadata to each packet: the packet type, the namespace and the ack id when a message acknowledgement is needed. That is why a WebSocket client will not be able to successfully connect to a Socket.IO server, and a Socket.IO client will not be able to connect to a WebSocket server (like ws://echo.websocket.org) either. Please see the protocol specification here.
So, you shouldn't expect Channels to work directly with Socket.IO. Global browser support for websockets is at 93%, which is probably high enough to just use the websocket API directly.
To quote the creator of django channels: https://github.com/django/channels/issues/1038
Channels doesn't support socket.io - it's a different protocol that isn't websockets or HTTP but layers on top of them. You'll have to use a socket.io server if you want to use it.
I'm developing a server using django. There are numbers of devices that connect to this server and send request periodically. How can I handle these requests properly?
You'll probably want to look into django signals to setup webhooks to listen for certain things to call other things etc... signals was built to keep your app in sync with changes being made throughout. https://docs.djangoproject.com/en/dev/topics/signals/
As I mentioned in the title: I would like to know the difference between the web-service and the web-socket? when we used each one?
Thanks!
A web service is an HTTP server that responds to client SOAP/REST/JSON requests.
A web socket is a client-side API that allows a web browser to create a bidirectional communication link with a server without having to change/reload the current page. This is typically used for AJAX requests to dynamically update live content on the current page, or create chat sessions between clients, or implement custom protocols that run in the web browser.
Web services are based on HTTP protocol and use HTTP methods to relay data in a request and response paradigm. Thus the client will always be the one responsible for communicating with the server, requesting data and submitting data to the server i.e getting list of customers or products, adding products or customers to server.
In contrast, Web sockets allow bidirectional communication, meaning server can initiate communication as much as client can do the same. Typically you supply a host IP Address and port to the socket. Web sockets can be used to implement a chat application.
The key difference between Web sockets and Web services is that with web sockets you get bi-directional connection in which the server and client can continuously send messages back and forth while Web services are uni-directional connection concerned with supplying clients with resources
I have a mini computer that does not support websockets that I would like to receive push notifications from a server.
The issue is that after the client connects to the server, the server responds and then closes the connection. This makes it so the client has to continually reconnect to the server to get new information.
Is there a way using Django to allow the connection to be left open and then have the server publish data to the client?
Django is primarily a request/response framework and as such does not have support for real duplex communication.
Socket.IO is the de facto library that makes websocket-like functionality cross-browser (IE5.5+), using real websockets as a transport if the browser allows it, falling back to HTTP long-polling or whatever else if it doesn't. For various options on integrating Socket.IO with Django, read this.