The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I'm confused...SignalR is not a message queue...it's a communication link. You would usually use SignalR in conjunction with a message queue if you needed message queuing. The client would connect with SignalR, then the SignalR thread would queue the item in the message queue system and wait for a response to send back to the client. The important distinction here is that the SignalR thread keeps a connection with the client in order to notify. It can sort of be used like a message queue, but it's main characteristic is the continued connection to the client for notification and there is no queue. There can be performance implications in that each call to SignalR can launch an action concurrently and you can overload the server, but with a message queue, you can control how many threads or processes are servicing each queue and never have more concurrent processes than that. Then you can have as many SignalR threads waiting around for results to send back to the client.
Are you using the .NET Full Framework or the .NET core? I only started with .NET core 2.1 and built distributed batch processing work queue and it's working fine and even has good performance, tested crossplatform and scaled on aws cloud without problems. I did experiment with large messages (10MB) but (de)serialization performance caused me to stick to small packets and strip of unnecessary data.
I have found that disabling all the fallbacks and forcing SignalR to use websockets makes a huge difference. Also if you are using nginx there is a config setting that limits the number of connections to 300 that you need to bump up.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
In my mission to raise the dead PCMCIA thing, I now have some hardware!. There is this MicroGate Systems SyncLink USB. The issue with this thing is the drivers, go to the website download the drivers
for 64 bit Win 10. Oh dear, the blessed thing still is not happy. Does Win 10 Admin mode reject drivers and need other approvals from Network Admins?...
Yes it does. It also rejects unsigned drivers as have all OSs since W7. I have not tried this with W10 but with W7 I could press F8 at boot time, it would give a menu, and I would tell it to load unsigned drivers and then everything would work OK.
Best of luck.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
If you are deploying the hardware to a "select few" you could create your own root certificate, create a driver certificate from that and sign the drivers.
You would then have to deploy the two certificates with the drivers. That would solve the problems with unsigned drivers....
Who the f*** is General Failure, and why is he reading my harddisk?
Not sure if this is relevant (or still works), but I remembered I had a link to this article, which shows how to disable/re-enable the driver signing check. You can skip the first half of the article, which explains how to hack some particular .INF file to make some NIC driver work with Server 2012 R2.
The important thing here--what you care about--is the set of bcdedit commands near the end of the article. I hope this helps.