Simple webserver

[Chris Angelico]

On Sun, 22 Oct 2023 at 04:13, Janis Papanagnou via Python-list
<python-list at python.org> wrote:
> 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.

Oh, sweet, sweet, then you should be fine with the library I
suggested. It's certainly served me well (and I have similar
experience, having learned networking mainly on OS/2 in the 1990s).

> 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.

Technically that's true, but "wait for request(s)" has to handle (a)
new incoming sockets, (b) messages from currently-connected sockets,
and possibly (c) sockets now being writable when previously they
blocked. So you have most of the work of async I/O. Since the
library's been built specifically for asyncio, that's the easiest.

> 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?

Pretty trivial, yeah. You shouldn't have too much trouble here I expect.

> (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.)

Yes, that's correct. You can't use plain sockets from inside a web
browser, mainly because they offer way way too much flexibility (JS
code is untrusted and is now running on your computer, do you really
want that to be able to telnet to anything on your LAN?). So
websockets are the way to go. There are other similar technologies,
but for this sort of "broadcast to connected clients" messaging
system, websockets rule.

ChrisA