SmartFox.Send() locks thread it's called from if it's already processing other packet

[wobidojt]

Hi there, I don't know whether to call this a bug-report or a feature-request, so I apologize for any formatting issues.

Ran into an issue with our Unity project recently where we're sending a larger packet, however any subsequent requests/packets we try to send while that larger packet is being processed lock up the thread they're sent from (in our case that's the Unity main thread) which is fairly problematic. This thread is completely locked until the larger packet finishes processing and is sent off.

We tracked the issue to a ThreadManager class, where the OutThread processes each request/packet from a queue on its own thread. While the OutThread is processing, it sets a lock. The issue is that the method EnqueueSend() from that same class uses the same lock, so our main thread stops while it waits for that lock to open up.
I can see how this is fine in majority of cases, since the thread sleeps for a couple of ms to allow for requests to queue up, but we have a couple of instances where we're creating larger requests or many smaller ones where we're running into this.
We can avoid having the main thread lock up by spinning up a new thread and calling SmartFox.Send() from that thread, but it doesn't solve the issue that no requests/packets are being handled while processing the larger packet. We have objects that are trying to send out data every update, but they can't because of the larger packet which takes anywhere from 0.1-10 sec to process (likely due to compressing it).

Ideally, it would be nice to have each request/packet processed on its own thread, since right now they're all queued up into the same thread. That way we can process a larger packet alongside all the smaller ones without delaying any packets or locking our main thread. Or at least be able to process a separate larger request/packet independently.

Cheers

[Lapo]

Hi,
how big is the request you're sending? I don't think I've ever seen a request locking up a thread for any significant amount of time,
unless we're talking about 100s of MBs, which would be not recommended under SFS.

We can avoid having the main thread lock up by spinning up a new thread and calling SmartFox.Send() from that thread, but it doesn't solve the issue that no requests/packets are being handled while processing the larger packet.

SmartFox is supposed to send messages in the order in which the Send() method was called. Sending concurrently would break the order in which packets are sent.

Ideally, it would be nice to have each request/packet processed on its own thread

Same problem as above. Plus with very fast packet rates it could spawn many threads which is pretty expensive, especially on non desktop hardware. Generally speaking you don't want that in a game that has to maintain a stable frame rate.

This sounds a bit like a corner case that could be handled differently. For example for large requests you could use HTTP so that you don't "clog" the TCP queue and send it "out of order" compared to other requests (SmartFox can run servlets via Tomcat over http/https).


Thanks

[AptitudeStudios]

Hello, I can't log in to my license server dashboard, and my products are not allowing more than 100 ccu. I have a 2000 CCU license. Could you help me out with this? it's creating more problems with the client? kindly update me on a resolution time of at least

[Lapo]

There was a dedicated thread in the main forum section "SFS2X Questions" started yesterday.
We had an ~8 hour blackout during the night (UTC time) due to a failed AWS scheduled updated. If you're currently having issues acquiring your license just restart the server and you should be up and running.

Thanks