I'm trying to receive pushes from the server as a client; using my test client as follows:
Client:
socket_client = socketio.test_client(app)
#socketio.on('hit_client')
def recieve_message(json_data):
print("Server has called!")
Server:
socketio.emit('hit_client', 'Hi Client!')
The server should be pushing and calling the hit_client channel, but that isn't being fired. However, the socket_client.get_received() has the emitted data. I thought the whole point of WebSockets was bidirectional communication (i.e. pushing function triggers)!
This is a very simple setup and it doesn't even seem to be working... Any help would be EXTREMELY appreciated. I've been slamming my head for hours.
The test client is not a Socket.IO client. It's only purpose is to help you write unit tests for your Socket.IO server. It is similar in concept to the Flask's test client for HTTP routes. It only makes sense to use it in unit tests.
When the server emits something to the client, the test client will just store it and make it accessible in your test code via the get_received call. It will not fire any events, since that is not its intended purpose.
If you want to implement a Socket.IO client in python, there is a package for that: https://pypi.python.org/pypi/socketIO-client. With this package, you can write a Python script that connects to the Socket.IO server and can send and receive events.
Related
I am trying to create a simple http server, that will take http requests from a client and interact with an application that listens on a port (on the same host).
My initial take on that was to create a BaseHTTPServer with custom definitions of GET,POST.
So when a request arrived on the server, the custom POST method would first create a socket for the communication with the underlying application. It then extract the data that needs to be passed to that application and write them through the socket. Then when the application to respond and pass that response to the response of the initial post request.
Even though that flow works at a degree, i feel that there is a much more appropriate solution to the problem.
in a nutshell, we have:
Server:
appA running on port 8000
http server on port 80
Client:
connect to http server and interact with appA through http requests.
e.g. post for sending data, get to receive response
Any thoughts on how to solve the problem more appropriately?
Maybe a library to handle sockets at a higher level (currently I am connecting to the socket and use select to read,write data). I think asyncio may have such capability?
In general how would somebody optimally approach that problem. (without getting in trouble of implementing stuff that are already there, like http server)
First important point for me: I want to implement websockets. I do not need the fallback options of socketIO.
I would like "my clients" to implement whatever they want, as soon as they stay to the websockets protocol. Namely something like: var ws = new WebSocket.
So.. if the server is Flask-SocketIO, will a simple js WebSocket work?
ADDIONAL NOTES:
Python first!
I am trying to set up a server which will respond only (actually only send) to websockets, no web page associated. (Yes, I am fine with WS and I do not need WSS, in case you ask ;) ).
I had a try on the server side with flask-sockets
https://github.com/kennethreitz/flask-sockets
but it is giving me some problems. Like closing immediately the connection and
beside many similar problems on the web I could not find a solution. Hard to debug too. So before I start developing a new server...
Sadly no, you cannot use a Socket.IO server with plain WebSocket clients. Sorry, that's not what Flask-SocketIO was made for.
(in case this isn't clear, this is the author of Flask-SocketIO speaking)
I'm working with django-websocket-redis lib, that allow establish websockets over uwsgi in separated django loop.
By the documentation I understand well how to send data from server through websockets, but I don't understand how to receive.
Basically I have client and I want to send periodically from the client to server status. I don't understand what I need to do, to handle receiving messages from client on server side? What URL I should use on client?
You can achieve that by using periodically ajax calls from client to server. From documentation:
A client wishing to trigger events on the server side, shall use
XMLHttpRequests (Ajax), as they are much more suitable, rather than
messages sent via Websockets. The main purpose for Websockets is to
communicate asynchronously from the server to the client.
Unfortunately I was unable to find the way to achieve it using just websocket messages.
I'm building an client application, which connect to a server and wait for signal from server to do something (think about chat app).
For example: user 1 has client 1 and 2, user 2 has client 3, the server would send the message to the channel "user 1" and only client 1 and 2 will have the message.
I know about Websocket and Long-polling, but can't find a server which is self-hosted and easy to test. Initially I want to make a proof-of-concept first before dive in later.
Nginx push stream seems to fit my need, I can create a channel, and notify all client connect to that channel, seem good enough to use, but I can't find any Python client implement
AutoBahn and some other Python server seem only create one channel and broadcast.
Can someone give me a correct direction.
have a look on Python tornado http://www.tornadoweb.org/.
It is in fact a non-blocking webserver and you have a WebSocketHandler object which might be very useful for what you want to do.
http://www.tornadoweb.org/en/stable/websocket.html
Regards
You can have a look at zeromq which implements a push-pull client server interface.
I'm currently writing a project in Python which has a client and a server part. I have troubles with the network communication, so I need to explain some things...
The client mainly does operations the server tells him to and sends the results of the operations back to the server. I need a way to communicate bidirectional on a TCP socket.
Current Situation
I currently use a LineReceiver of the Twisted framework on the server side, and a plain Python socket (and ssl) on client side (because I was unable to correctly implement a Twisted PushProducer). There is a Queue on the client side which gets filled with data which should be sent to the server; a subprocess continuously pulls data from the queue and sends it to the server (see code below).
This scenario works well, if only the client pushes its results to the manager. There is no possibility the server can send data to the client. More accurate, there is no way for the client to receive data the server has sent.
The Problem
I need a way to send commands from the server to the client.
I thought about listening for incoming data in the client loop I use to send data from the queue:
def run(self):
while True:
data = self.queue.get()
logger.debug("Sending: %s", repr(data))
data = cPickle.dumps(data)
self.socket.write(data + "\r\n")
# Here would be a good place to listen on the socket
But there are several problems with this solution:
the SSLSocket.read() method is a blocking one
if there is no data in the queue, the client will never receive any data
Yes, I could use Queue.get_nowait() instead of Queue.get(), but all in all it's not a good solution, I think.
The Question
Is there a good way to achieve this requirements with Twisted? I really do not have that much skills on Twisted to find my way round in there. I don't even know if using the LineReceiver is a good idea for this kind of problem, because it cannot send any data, if it does not receive data from the client. There is only a lineReceived event.
Is Twisted (or more general any event driven framework) able to solve this problem? I don't even have real event on the communication side. If the server decides to send data, it should be able to send it; there should not be a need to wait for any event on the communication side, as possible.
"I don't even know if using the LineReceiver is a good idea for this kind of problem, because it cannot send any data, if it does not receive data from the client. There is only a lineReceived event."
You can send data using protocol.transport.write from anywhere, not just in lineReceived.
"I need a way to send commands from the server to the client."
Don't do this. It inverts the usual meaning of "client" and "server". Clients take the active role and send stuff or request stuff from the server.
Is Twisted (or more general any event driven framework) able to solve this problem?
It shouldn't. You're inverting the role of client and server.
If the server decides to send data, it should be able to send it;
False, actually.
The server is constrained to wait for clients to request data. That's generally the accepted meaning of "client" and "server".
"One to send commands to the client and one to transmit the results to the server. Does this solution sound more like a standard client-server communication for you?"
No.
If a client sent messages to a server and received responses from the server, it would meet more usual definitions.
Sometimes, this sort of thing is described as having "Agents" which are -- each -- a kind of server and a "Controller" which is a single client of all these servers.
The controller dispatches work to the agents. The agents are servers -- they listen on a port, accept work from the controller, and do work. Each Agent must do two concurrent things (usually via the select API):
Monitor a well-known socket on which it will receive work from the one-and-only client.
Do the work (in the background).
This is what Client-Server usually means.
If each Agent is a Server, you'll find lots of libraries will support this. This is the way everyone does it.