🔒 What's the best way to keep a UDP server active and waiting for data?

[alpine cipher]

I have this UDP server, and I'd like to keep it active, but putting it in a permanent while loop doesn't feel right to me. I'm concerned it could lead to fork-bombs and extensive CPU usage. It's also blocking, which I don't like. Are there safer alternatives?

https://paste.pythondiscord.com/PL5A

I haven't asked ChatGPT yet, I've been trying to avoid it.

[blazing escarp]

@alpine cipher

Python help channel opened

Remember to:

• Ask your Python question, not if you can ask or if there's an expert who can help.
• Show a code sample as text (rather than a screenshot) and the error message, if you've got one.
• Explain what you expect to happen and what actually happens.

:warning: Do not pip install anything that isn't related to your question, especially if asked to over DMs.

Closes after a period of inactivity, or when you send !close.

[twin moon]

A while loop is just fine. You're just receinving packets forever. That what while True: means.

[elfin pelican]

The official sample already shows some approach you can follow, https://docs.python.org/3/library/asyncio-protocol.html#udp-echo-server

[tacit gyro]

why would there be fork bombs?

[alpine cipher]

I've encountered some weird stuff when working with sockets.

[tacit gyro]

?

nothing about sockets makes your processes fork

[twin moon]

No, but the OP spawns a thread for every packet. Feels a bit overkill for an echo.

[tacit gyro]

that's...insane

[twin moon]

Shrug. Generalises to doing other things I guess. Anyway, it's not hard to limit the threads in play or something like that.

[tacit gyro]

at the very least a thread pool should be used

[twin moon]

or, since I'm lazy and low level, a semaphore

[alpine cipher]

The purpose for the threading is the calculation that's eventually going to take place on each of those threads.

[twin moon]

You probably still want to set a limit on them 🙂

[teal wind]

There are safer alternatives I already built a socket framework to handle this greatfuly both handshake and unpacking request

Read docs about it

https://github.com/pythos-team/lynk

!pypi lynkio

[blazing escarp]

lynkio v1.1.4

Lynk – Python only Realtime Server FrameworkHTTP + WebSockets + Database in one engine.No dependencies.

Released on <t:1773218999:D>.

[tacit gyro]

giving external users the ability to spawn an unlimited number of threads is a recipe for a disaster

_handler() could use a match block – it's making unnecessary comparisons

[alpine cipher]

Like a fork bomb. I'm planning on adding thread limits later, but am laying out the basic protocol at the moment. Each node will hold about 5,000 users. And they'll need to navigate to and register with their closest node. User IDs will be generated (for them) by hashing their ed25519 keys, and having them sign a network registration that gets stored on the distributed node network.

[alpine cipher]

Thanks. I'll look into it.

[tacit gyro]

https://paste.pythondiscord.com/ZXBQ

[alpine cipher]

That is much easier, thank you.

[tacit gyro]

@alpine cipher this could be a starting point for you: https://paste.pythondiscord.com/KZBQ

[teal wind]

Yes but note if you are building full websocket compatible, you to handle handshake and send a pong the browser understand, and also you need to handle reconnecting gracefully when browser disconnects clients, there are more to feed it, (max_payload, rate limit etc) so they don't starve your connection,

Or you are just building something outside socket?

[alpine cipher]

I didn't come here for free work (unless you want to), but thanks for the assist. This looks good.

[alpine cipher]

I'm not planning for web sockets. I don't think Chrome will be around much longer, at least in its current form (Android is offering a native desktop experience, Chrome seems to be shifting to web apps, a lot of native apps are getting crappy, a lot of people I know are moving away from smartphones because of the spying). So, I'm focusing on UDPs for low-level clients.

[alpine cipher]

Essentially, I'm seeing something like MeshCore, where each cluster has a few dedicated online central nodes. The devices broadcast a signed registration, which gets put into this network. Then, when those nodes receive messages, they can forward them to their respective devices.

[alpine cipher]

I tried working with Nodejs, but its BigInt library was horrible.

[teal wind]

Hmm am not familiar with nodejs, i did thought about what you said well the lynkio I built only supports TCP so base on the benefits of UDP for game streaming and more not because brower would change lynkio is a framework not for building only web apps you make it fit what you want,

I will make lynkio support protocol switching automatically

user would have to specify a particular protocol to use,

Building something like this isn't about just knowing how to code if you understand the architecture you can build it,

Explain if UDP is supported

device → UDP packet → server

I would make lynkio support UDP

[alpine cipher]

My main support for UDP comes from holepunching. You send me a message. I send you one. Your router could be firewalled, and it'll let my message through, because you made the connection first. TCP holepunching is a lot more complicated.

[tacit gyro]

that would involve UPnP, yes?

[teal wind]

Alright expect lynkio v1.1.5 to support UDP I want to add it up, you just manually switch protocol, TCP or UDP

[tacit gyro]

your packaging setup could use an update

[teal wind]

Like pypi? So I don't bump version?

[tacit gyro]

it lacks the standard pyproject.toml project manifest

I'm not sure recent versions of pip will even install this thing

and it contains non-standard requirements.txt files

[teal wind]

Setup.py alone can build a package lynkio is pure python libs no external

[teal wind]

Yes nothing to install

[tacit gyro]

???

none of what you're saying makes sense

[teal wind]

The requirements.txt would be deleted in next push it is not needed am cleaning the repo

[tacit gyro]

are you adding a pyproject.toml?

[teal wind]

I would

[tacit gyro]

ok

the project also lacks any kind of a test suite

[alpine cipher]

As far as I've read, holepunching doesn't involve UPnP. UPnP requires other protocols, like http. UDP holepunching is basically, you send my server a UDP packet from your "server"'s address. Then my server responds on that same ip:port. The router assumes you want the data, because you just connected to me on that port.

[tacit gyro]

which I see as a red flag

[teal wind]

Read doc

[teal wind]

Read readme

[tacit gyro]

which part in particular?

[teal wind]

quickstart in docs

[tacit gyro]

I have, but how does that relate to the lack of a test suite?

[teal wind]

Alright expect that on v1.1.5 everything would be available on GitHub so you get automatic test, I taught quickstart could solve that

[tacit gyro]

You can't get a test suite automatically, you have to write one yourself

it's easily one of the most arduous parts of any project, but a vital component nonetheless

[teal wind]

Yes I know I already built 2 projects with it, so if I add UDP if I put change I push with a test.py maybe that would satisfy that right?

[tacit gyro]

I missed the fact that you had a test.py; it was not where I expected

[teal wind]

Ok did that test got what you are looking for?

[tacit gyro]

I can't tell what the test coverage is

and as you mentioned, you need to automate the testing

[teal wind]

Yes you won't get familiar with it easily with time, that test.py is for stress testing lynkio developer API, I recommend using the one in the app.py, or wait for the latest push so I sort everything nicely both simple testing and stress testing

test1.py
test2.py

All sorted this way

[tacit gyro]

I suggest you move them to a separate folder for easier collection with pytest

[blazing escarp]

Python help channel closed for inactivity

This help channel has been closed. Feel free to create a new post in #1035199133436354600. To maximize your chances of getting a response, check out this guide on asking good questions.