I am pondering about writing a client/server software with
websockets as communication protocol. The clients will run
in browser as Javascript programs and the server may be in
any (any sensible) programming language running standalone
to be connected remotely by the browser-based JS clients.
I found a Python sample[*] but I am neither familiar with
Python nor with the 'simple_websocket_server' package that
is used in that sample code. But the code looks so simple
that I'm considering to learn and use Python for the task.
The requirements I have are quite simple; I want to get the
client "address"/identifier from an incoming message, store
it in a list, and send responses to all active clients for
which addresses have been stored.
Can anyone tell me whether a simple extension of that "echo
incoming message" sample[*] would be easily possible with
Python and with that 'simple_websocket_server' package used?
Thanks for any hints (or search keywords, or code samples)!
The requirements I have are quite simple; I want to get the
client "address"/identifier from an incoming message, store
it in a list, and send responses to all active clients for
which addresses have been stored.
[snip]
Hope that's enough to get you started! I'd be delighted to help
further if you run into difficulties.
Broadly speaking, your ideas are great. Any programming language CAN
be used for the server (and I've used several, not just Python).
On 19.10.2023 01:23, Chris Angelico wrote:
Broadly speaking, your ideas are great. Any programming language CAN
be used for the server (and I've used several, not just Python).
Out of curiosity; what where these languages? - If there's one I
already know I might save some time implementing the server. :-)
On Fri, 20 Oct 2023 at 22:31, Janis Papanagnou via Python-list
<python-list@python.org> wrote:
On 19.10.2023 01:23, Chris Angelico wrote:
Broadly speaking, your ideas are great. Any programming language CAN
be used for the server (and I've used several, not just Python).
Out of curiosity; what where these languages? - If there's one I
already know I might save some time implementing the server. :-)
I've done websocket servers in Python, Node.js, and Pike, and possibly
others but I can't recall at the moment. Might have done one in Ruby,
but that would have just been part of playing around and comparing
features ("how easy is it to do <X> in Ruby").
ChrisA
I found a Python sample[*] but I am neither familiar with
Python nor with the 'simple_websocket_server' package that
is used in that sample code. But the code looks so simple
that I'm considering to learn and use Python for the task.
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
I found a Python sample[*] but I am neither familiar with
Python nor with the 'simple_websocket_server' package that
is used in that sample code. But the code looks so simple
that I'm considering to learn and use Python for the task.
I've generally used ThreadingServer(SocketServer) for this purpose
and I think threads are less confusing than async, and performance is
fine if the concurrency level is not too high. But, trying to write a
web server in Python if you don't know Python doesn't seem like a great
idea, except as a learning project.
I have a couple decades experience with about a dozen programming
languages (not counting assemblers). Asynchronous processing, IPC, multi-processing, client/server architectures, multi-threading,
semaphores, etc. etc. are concepts that are not new to me.
My expectation would be that any sophistically designed socket/
web-socket library would not impose any risk. And the intended
server by itself has only very limited requirements; listening to
incoming request, storing some client information, broadcasting
to the attached clients. Basically just (informally written):
init server
forever:
wait for request(s) -> queue
handle requests from queue (sequentially):
store specific information from new registered clients
broadcast some information to all registered clients
It seems to me that multi-threading or async I/O aren't necessary.
I'd like to ask; where do you see the specific risks with Python
(as language per se) and it's (web-socket-)libraries here?
If the web-socket IPC is well supported the algorithmic parts in
Python seem trivial to learn and implement. - Or am I missing
something?
(A brief search gave me the impression that for JS communication
web-sockets would be the method to use. Otherwise I'd just use
basic Unix domain sockets for the purpose and write it, say, in
C or C++ that I already know. But I don't know whether (or how)
plain sockets are used from JS running in a browser. Here I'm
lacking experience. And that lead me to have a look at Python,
since the web-sockets/server examples that I found looked simple.)
...
I'd like to ask; where do you see the specific risks with Python
(as language per se) and it's (web-socket-)libraries here?
I am pondering about writing a client/server software with
websockets as communication protocol. The clients will run
in browser as Javascript programs and the server may be in
any (any sensible) programming language running standalone
to be connected remotely by the browser-based JS clients.
I found a Python sample[*] but I am neither familiar with
Python nor with the 'simple_websocket_server' package that
is used in that sample code. But the code looks so simple
that I'm considering to learn and use Python for the task.
The requirements I have are quite simple; I want to get the
client "address"/identifier from an incoming message, store
it in a list, and send responses to all active clients for
which addresses have been stored.
Can anyone tell me whether a simple extension of that "echo
incoming message" sample[*] would be easily possible with
Python and with that 'simple_websocket_server' package used?
Thanks for any hints (or search keywords, or code samples)!
Janis
[*] https://pypi.org/project/simple-websocket-server/
The web server in Python's runtime library is fairly simple,
focusing only on the HTTP requirements.
You might want additional things for an HTTP server
exposed on the internet which should potentially handle high trafic:
e.g.
* detection of and (partial) protection against denial of service attacks,
* load balancing,
* virtual hosting
* proxing
* URL rewriting
* high throughput, low latency
Depending on your requirements, other web servers might be preferable.
2. Instead of running as a stand-alone server, run my app as a
reverse-proxy using Nginx. I tested this a few years ago using Apache,
and it 'just worked', so I am fairly sure that it will work with Nginx
as well. Nginx can then provide the additional functionality that Dieter
has mentioned.
My main concern is that, if I do release my app, I want it to be taken seriously and not dismissed as 'Mickey Mouse'. Do you think the above
changes would assist with that?
When I talk about releasing it, it is already available on Github here - https://github.com/FrankMillman/AccInABox.
You are welcome to look at it, but it needs a lot of tidying up before
it will be ready for a wider audience.
...
Based on this, I am considering the following -
1. Replace my HTTP handler with Uvicorn. Functionality should be the
same, but performance should be improved.
2. Instead of running as a stand-alone server, run my app as a
reverse-proxy using Nginx. I tested this a few years ago using Apache,
and it 'just worked', so I am fairly sure that it will work with Nginx
as well. Nginx can then provide the additional functionality that Dieter
has mentioned.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 446 |
Nodes: | 16 (2 / 14) |
Uptime: | 19:28:41 |
Calls: | 9,234 |
Calls today: | 1 |
Files: | 13,494 |
Messages: | 6,063,226 |