|
Me and my colleagues at work have totally had it with SignalR and it's erratic behaviour, everything seems to work fine locally, but as soon as it's tested in a production environment unexplainable problems occur. Also there does not seem to be anything to find about these problems on the internet, like long delays on message delivery 
Are we the only ones having these problems ?
We are thinking about switching to ZeroMQ, see: message-queue-servers[^]
|
|
|
|
|
Pretty much anything of that sort is created by architecture astronauts and will not fullfil any particular need.
|
|
|
|
|
PIEBALDconsult wrote: architecture astronauts
This is priceless. Will be reused.
|
|
|
|
|
Apparently Joel Spolsky coined it.
Look it up.
|
|
|
|
|
Here[^] for those interested.
Nice one, thanks.
|
|
|
|
|
I would suspect firewall or configuration issues on the production server, or even routing (though unlikely for most network configurations).
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
We have some knowledgeable network administrators, and they could not find any problems, besides all other software using TCP worked without any problems !
|
|
|
|
|
Why not RabbitMQ (which is first on that list and also the most well known by far)?
Worked with it and it worked pretty well (never tried front-end though).
I'm currently using Azure ServiceBus which also works great (but somehow isn't on that list).
What kind of problems are you having with SignalR?
I'm thinking about using it in a project of my own (in Azure), but this doesn't bode well 
|
|
|
|
|
Sander Rossel wrote: also the most well known by far
That doesn't speak well of the circles I hang out in. I HAVE heard of SignalR but NOT RabbitMQ.
SignalR is the most popular one I have heard about. 
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
They're different technologies.
SignalR is a wrapper around web sockets that can send data back to the browser (which isn't normally possible using HTTP, although SignalR should fallback to long polling if sockets fail or aren't supported).
RabbitMQ (and ZeroMQ and ServiceBus) are queueing technologies, which support sending some data to a queue (or topic) where listener(s) will pick it up and do something with that data.
I can see how queueing can be an alternative to sockets, but sockets are usually not a good (or even possible) alternative to queues.
|
|
|
|
|
That looked good to me too, and also NATS (especially with future Docker microservices development in mind), but one of my colleagues already beat me to it with a Proof of Concept using ZeroMQ before I could even start a discussion about it, guess I'm getting too old and slow 
And I must say, the more I read about ZeroMQ the more enthousiastic I get, it's even developed by a Dutch guy !
|
|
|
|
|
Never heard of NATS (just read your experience on that list).
My biggest objection to ZeroMQ would be the following:Some guy named Tim wrote: More complicated scenarios require more setup
ZeroMQ is very fast due to its simplicity, but as a result of this, doing anything harder than passing messages between 2 peers will require a lot more work from the user.
SignalR is (usually) a one-to-many broadcast, with support for channels.
That sounds more like topics than queues, and according to this Tim topics aren't supported in ZeroMQ.
RabbitMQ (and ServiceBus) do support topics out of the box.
Although reading the ZeroMQ website it also seems they support topics as well, so Tim might just be a dirty little liar
|
|
|
|
|
ZeroMQ's fine - I've used it in some projects at work. I've always got the feeling that Martin Sustrik (who then went on to start nanomsg - another lightweight messaging system) was the main man in the development, until him and Hintjens had a falling out...
Main difference between ZeroMQ & other messaging systems is the lack of a separate broker server, which is an advantage for some use cases (it was for the one we had), but probably not for others. Being able to support messaging between & within processes (where in-process messaging uses a different, more efficient transport) was also a plus point for us.
We only use the REQ-REP setup, but PUB-SUB (for data distribution) is also on the cards for future developments.
We layered Protocol Buffers on top, to provide message structure. That also worked well.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Thanks, useful information !
|
|
|
|
|
I thought RabbitMQ was a message que system. Does RabbitMQ implement WebSocket type of technology?
|
|
|
|
|
I didn't think so, but then I found RabbitMQ Web STOMP Plugin — RabbitMQ[^].
I'm not sure how Rick wants to implement queueing in a browser, but with over 350,000 packages in the npm repository I'm sure there's one for connecting your queue to JavaScript
|
|
|
|
|
I'm always interested in talking about "WebSocket" technology.
I'm using Firebase in a project right now and I've created a firebase example you may find interesting.
Here is the most simple example where you can move a game pawn in your browser window and see it move (across the Internet) in the other person's browser.
pawns[^]
I also wrote up an article on SignalR, but unfortunately it is using a little older version of SignalR : Beginner's Guide to Using SignalR via ASP.NET[^]
Possible Way To Test?
You may like to open the browser on a few different devices and try it out to see if you see the same problems you are seeing in your app. If you see the problems it may be the firewall or network you are on.
Here's a direct link to the SignalR one you can try:
pawns[^]
It's a weird URL but that is because I wrote it a while back and the URL that it is coded up with is very important in the over all project. It's just anonymous link to my web site: raddev.us
You can test simply by moving a game pawn around and seeing it move in other browsers.
Open up a few browser windows and try it out and let me know.
|
|
|
|
|
Thanks, I tried your pawns application (years ago I think) and that worked ok. The problem with our implementation might be that we use the self-hosted version of SignalR and a mix of .NET and .NET Core applications.
Can't give more details because only my colleagues have full insight in this complex software.
|
|
|
|
|
RickZeeland wrote: Can't give more details because only my colleagues have full insight in this complex software.
I totally understand. My example is the most simple and basic thing possible, but when delving into real solutions things get complex fast. Wish I had more info to give you help but I know even with my simple example I ran into some real challenges.
Good luck.
|
|
|
|
|
|
Thanks I really appreciate that. 
SignalR and WebSocket tech is really interesting, but SignalR can be quite confusing to work with -- challenges with auth and security, etc. and getting it to work when deployed.
|
|
|
|
|
It sounds to me like another MS com tool that requires a lot of configuration and is too easy to break: WCF. When it works it works great, but when it doesn't it's very stubborn about it!
|
|
|
|
|
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.
|
|
|
|
|
Just a wild stab in the dark, but is Symantec Endpoint Protection involved in the equation?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Good one, we'll check that !
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
