Subnostr

Yeah I'm reading that elsewhere too. So a given computer can only connect to my chorus port 64k times over, but each other computer on the Internet can also connect to my chorus port 64k times over. [In actuality most systems have less than half that many port numbers available for this purpose, still it is overkill].

Brunswick 1y ago

So all it would take is about 20 machines with separate IP addresses and a malicious websocket client to open 50k connections and open 1M connections with keep-alive traffic and attempt a ddos (even if it takes some time with the initial connection rejections).

Fortunately since each thread can handle multiple websockets, your implementation may be able to handle it. On the other hand, once all those connections are open, it would be trivial to perform a simultaneoushigh-demamd filter-query request.

Reply to this note

Please Login to reply.

Discussion

Mike Dilger ☑️ 1y ago

I'd like to try it.

"In theory there is no difference between theory and practice, but in practice there is."

Mike Dilger ☑️ 1y ago

Don't do it to my current machine. This was not permission to DDoS my domain! Hehe. I'd have to arrange it with the data centre first.

Brunswick 1y ago

If you have only one thread per cpu, does that mean any requests from the sockets on that cpu are queued?

Mike Dilger ☑️ 1y ago

Sockets are not pinned to CPUs. Any thread (cpu) can pick up any task that is ready for further processing.

Brunswick 1y ago

Are the requests process asynchronously from the database, for example, the requests are processed by one queue, but the database lookup is dispatched by the request processor, then the result is returned after the database has returned data. Such as; if you have two clients (A and B) making two separate requests, if A is processed before B (both in the same request handling thread), but the lookup for B returns data to be sent back before A, then B would get its respomse before A?

Mike Dilger ☑️ 1y ago

Yes it is all asynchronous. Within 'async rust', everything is asynchronous. There is no tricky coding on my part. Every function that says it returns a type T actually returns a future that resolve to a type T and the executor handles running that future to completion, even as that task sometimes returns Poll::Pending instead of Poll::Ready(data) in which case it gets shelved so the thread can keep itself busy with anything else that needs to be done. This is all internal to rust's async system and the executor which I use which is 'tokio' (there is another one async-std, but I don't think it ever got much uptake).

Mike Dilger ☑️ 1y ago

I take this back, see other response to the parent.

Brunswick 1y ago

So rust's async is more like green thread than like microsoft's WDM deferred procedure calls?

Mike Dilger ☑️ 1y ago

yep

Mike Dilger ☑️ 1y ago

BTW it doesn't just repeatedly poll and keep getting Poll::Pending. When it gets one of those, it doesn't poll again until the waker system wakes up the task when the I/O is actually ready.

Mike Dilger ☑️ 1y ago

Shit, I seem to have entirely failed to async in the chorus-lib. Huge oversight.

Mike Dilger ☑️ 1y ago

Eh, nah it looks like `heed` (the LMDB library) isn't async so I couldn't do it if I wanted to. Data access is memory-mapped, and any delays happen in the kernel (I think) and are kind-of hidden to the application (kernel handles the page fault, our code is put to sleep while that happens), so hard to async in userspace in this case, but it should be fast nonetheless. Potentially a thread sleeps over a page fault when the CPU could have otherwise been busy, but probably not something we can fix.

All network waits are definately async futures.

Brunswick 1y ago

The test could be run on an internal private network fairly easily. Each client could be on a separate VM, possibly even all 20 clients could be on one machine and it done with the bridge interfaces of docker containers.