I think I'm wrong. I've got TCP/IP illustrated vol1 and 2 right here on the bookshelf. Shall I learn?
Discussion
Here is what gpt4 says:
"In TCP/IP networking, a connection is uniquely identified by a tuple consisting of the source IP address, source port, destination IP address, and destination port. While the port number is a 16-bit number, limiting the number of ports to 65,536 per IP address, the distinction between connections is made based on the combination of these four elements, not just the port number."
It sounds like this is a posix-sockets layer capability. On the other hand, each open socket requires a open file handle, so it can be constrained in limits.conf
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].
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.
I'd like to try it.
"In theory there is no difference between theory and practice, but in practice there is."
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.
If you have only one thread per cpu, does that mean any requests from the sockets on that cpu are queued?
Sockets are not pinned to CPUs. Any thread (cpu) can pick up any task that is ready for further processing.
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?
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).
I take this back, see other response to the parent.
So rust's async is more like green thread than like microsoft's WDM deferred procedure calls?
yep
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.
Shit, I seem to have entirely failed to async in the chorus-lib. Huge oversight.
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.
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.
I read vol1. Didnt know about vol2