Meteor itself has the possibility to open a DDP connection to a DDP server - also from the server - which I though was worth playing around with.
Meteor provides me with methods and subscriptions. Both can (speaking in the DDP context) only be started by and send data to the client.
How could I set up a connection from a meteor installation behind an NAT network (that's the reason why it must be him setting up the connection) to a meteor installation - let's say it's in the cloud - and let it subscribe to a dataset of the installation behind the NAT?
Only the client of the DDP communication can subscribe to a publication, published by the server, right - or is there a possibility missed out? It should more or less be like a pipeline or caching system having a subset of data, that sends changes back to the installation in the cloud.
As far as I can see, the specification of the DDP protocol, which Meteor uses to exchange data, doesn't have an option to realize a solution like mine. It would have been nice though ...
I now either would have to extend DDP by the desired behavior or find another way.
I'd be happy if someone proofs my answer wrong.
You can't do this usual way, unfortunately. Only client-side of connection can subscribe or call methods, not the vice-versa.
You can, though, use meteor-streamer package that allows you 2-way communication between client/server. Thus, you'll be able to organize needed observer inside your NAT-app and send notifications to your cloud app.
Related
I have to connect an old but critical software to RabbitMQ. The software doesn't support AMQP, but it can do HTTP Requests.
Does RabbitMQ support plain HTTP? Or should I use a "proxy" or "app" that actively transforms the HTTP Requests to AMQP 1.0 and pushes it to the RabbitMQ server?
https://www.rabbitmq.com/management.html
The management plugin supports a simple HTTP API to send and receive messages. This is primarily intended for diagnostic purposes but can be used for low volume messaging without reliable delivery.
As mentioned, it's designed for very low loads, but it may be usable. If you need higher loads, then by all means cast around for a library that does the job and create a proxy. Most languages will have something. I've personally created a lightweight API using Lumen and https://github.com/bschmitt/laravel-amqp to tie a few disparate services together in the past, and it seems to work very well.
It is possible not but really recommended depending on load. You have three options really, two of which are web socket based and one that seems like what you're looking for. I'd suggest starting with the rabbitmq docs.
I want to create a web app using React as the front end technology. A requirement for the app is that the server will be able to update all the clients with information about changes (not have to be an exact real time, but should update after no more than 10 seconds).
Solutions like clients requesting updates from the server every several seconds are out of the question.
Requirements:
1) The server's should be implemented with either .NET or with Node.js.
2) The connection MUST be secured via port 443 of the IIS.
I read a bit about Micorsoft's SignalR and about Pusher Channels which seems to provide exactly the kind of service I require.
Could you please elaborate about what exactly are the differences between them? When should I choose each? Which of them got more community support? Which is easier to implement? Stuff like that...
Both SignalR and Pusher Channels ultimately both use websockets to deliver messages to clients, so both should meet your requirements to deliver messages to clients in realtime.
1) Both offerings also meet your requirements for both library support:
SignalR supports .NET:
https://dotnet.microsoft.com/apps/aspnet/signalr
Pusher Channels has server support for both nodejs and .NET:
https://github.com/pusher/pusher-http-node
https://github.com/pusher/pusher-http-dotnet
2) Both offerings also meet your requirements for sending messages over TLS/WSS:
SignalR:
https://kimsereyblog.blogspot.com/2018/07/signalr-with-asp-net-core.html
Pusher Channels:
Securing Pusher's messages
In terms of the differences between them this depends on your implementation, if you just run SignalR on your own ISS server then it will be down to you to manage all of the websocket connections and all of the scaling challenges that come with this.
However similar to how Channels works, SignalR also has a managed websocket service, so you do not need to manage the connections or scaling. You just make an API request with the message you want to send to either Channels or SignalR and this message is then broadcast to the interested clients connected by websockets. In this scenario you do not manage the websocket connections yourself.
However in terms of pricing Channels appears to be far more competitive (especially the free offering), so if you are looking at the managed offering Channels looks to be a better value proposition:
https://azure.microsoft.com/en-gb/pricing/details/signalr-service/
https://pusher.com/channels/pricing
Both offerings look fairly similar in terms of implementation (assuming you are using the managed service). The complexity would increase if you implement SignalR on ISS:
https://learn.microsoft.com/en-us/aspnet/core/signalr/scale?view=aspnetcore-2.2
In terms of support Pusher has a free application support offering:
https://support.pusher.com/hc/en-us
Hope this helps!
This presentation has some answers A 10 Minute Guide to Choosing a Realtime Framework
So, there we've got a client-server interaction via ZMQ and have stucked into an architectural arguing about the proper pattern fitting our needs. I hope that someone wise and experienced may help resolve it.
It's not essential, but I need to mention that ZMQ is not being used directly, it's rather a Qt binding with C++ over the library itself, so low-level customizations are possible but undesirable (they would increase implementation efforts significantly).
Current architecture
There was a need of some reliable, convenient & robust API broker, the one's been implemented via REQ <-> REP: statuses, error codes, encryption, etc. Encryption 's been implemented via separate authorization SSL channel, providing API with session keys, it's mentioned here to empasize that as far as SSL has not been provided at ZMQ's socket level (looked too complex), "session keys" exist (symmetric encryption key per client), it limits pattern solutions somehow.
So, there exist requests (client) + responses (server), it works. But we've recently met a need in some notification mechanizm for clients. Let's say the current broker API provides some types of data: X, Y, Z (lists of something). The client can get any of them but it has to be notified when any changes in X or Y or Z occur in order to know that new requests are to be done.
The problem
Obviously, clients should receive either data updates or notifications that such updates exist. It could be a mere PUB-SUB problem, but it seems almost impossible to make this solution encrypted, or at least authorization-aware (not mentioning really "crutchy" ways to do it).
After some discussion two opinions appeared, describing two different workarounds:
Still use PUB-SUB, but only send notification type to the subscribers, like "hey, there's new X present". Clients-subscribers would have to perform already implemented API requests (REP-REQ) with session keys and all. Advantages: easy and working. Disadvantages: client logic complication.
Just rewrite API to use couples of ZMQ_PAIR sockets. Results in client-server behavior similar to plain sockets, but notifications can be "sent back" from server. Advantages: simple scheme. Disadvantages: rewriting, also broker won't differ much from a simple socket solution.
Question
What would you adwise? Any of the descibed solutions or something better, maybe? Possibly X-Y problem exists here? Maybe something is considered a common way of solving problems like that?
Thanks in advance for any bright ideas.
ZMQ_PAIR socket are mainly used for communication between threads so I do not think they are a good solution for a client/server setup, if it all possible.
You could use ROUTER/DEALER instead of REQ/REP as they allow other patterns than just request/reply. I think newer version of ZeroMQ provide SERVER/CLIENT as a better alternative but I have not used them myself.
However, I would prefer a solution with a separate PUB/SUB channel because:
You don't have to change the existing REQ/REP protocol.
It allows only clients that are interested in notifications to connect to the PUB socket and process notifications. Other clients can use just the existing REQ/REP protocol.
PUB/SUB can automatically send notification to multiple clients.
PUB/SUB allows subscribing to specific notifications only.
It's seems to me that SignalR is only temporary step towards global domination of System.Web.WebSocket, and it's lower level System.Net.WebSocket.
If I have IIS8, and my clients have IE10, do I have any reason to use signalR?
Does it have a future?
(Of course, the same goes for Socket.IO + Node.js)
Thanks
ref:
http://pieterderycke.wordpress.com/2012/07/20/websockets-vs-signalr-or-why-you-should-not-have-to-care/
A number of advantages:
SignalR abstracts the actual connection type away so that you only deal with a logical connection. The advantage is that you can switch to other connection types if you want to without having to change your code (SSE might actually provide better performance than WebSockets in some cases).
You get the fallback options (long-polling etc.) for free in case you need to connect from a client that doesn't support WebSockets.
Hubs provide a level of organization (you can do that yourself, of course, but it's a good starting point, and it's convenient)
SignalR provides a rich API for calling a specific client, a group of clients, all clients (including the ability to exclude certain clients). Again, you can implement it yourself, so this is mostly about convenience.
You can pass strongly typed parameters between client and server (both ways).
You'll (probably) have to deal with less boilerplate code with SignalR.
Scale-out support
Off the top of my head, the group membership/broadcast and the ability to scale out on a webfarm are features that you don't get built into the WebSockets classes - so if you're using those features, you'll probably continue to use SignalR for the near future.
Additional to Damien's points:
SignalR also supports long polling and some other techniques if the user has no browser with web socket support
It's very easy to call methods on the client from the server
Also, when WebSockets is updated, SignalR will also be updated, so you won't need to worry about coding for the new version of WebSockets.
I am searching for a good method to transfer data over internet, and I work in C++/windows environment. The data is binary, a compressed blob of an extracted image. Input and requirements are as follows:
6kB/packet # 10 packets/sec (60kBytes per second)
Reliable data transfer
I am new to network programming and so far I could figure out that one of the following methods will be suitable.
Sockets
MSMQ (MS Message Queuing)
The Client runs on a browser (Shows realtime images on browser). While server runs native C++ code. Please let me know if there are any other methods for achieving the same? Which one should I go for and why?
If the server determines the pace at which images are sent, which is what it looks like, a server push style solution would make sense. What most browsers (and even non-browsers) are settling for these days are WebSockets.
The main advantage WebSockets have over most proprietary protocols, apart from becoming a widely adopted standard, is that they run on top of HTTP and can thus permeate (most) proxies and firewalls etc.
On the server side, you could potentially integrate node.js, which allows you to easily implement WebSockets, and comes with a lot of other libraries. It's written in C++, and extensible via C++ and JavaScript, which node.js hosts a VM for. node.js's main feature is being asynchronous at every level, making that style of programming the default.
But of course there are other ways to implement WebSockets on the server side, maybe node.js is more than you need. I have implemented a C++ extension for node.js on Windows and use socket.io to do WebSockets and non-WebSocket transports for older browsers, and that has worked out fine for me.
But that was textual data. In your binary data case, socket.io wouldn't do it, so you could check out other libraries that do binary over WebSockets.
Is there any specific reason why you cannot run a server on your windows machine? 60kb/seconds, looks like some kind of an embedded device?
Based on our description, you ned to show image information, in realtime on a browser. You can possibly use HTTP. but its stateless, meaning once the information is transferred, you lose the connection. You client needs to poll the C++/Windows machine. If you are prety confident the information generated is periodic, you can use this approach. This requires a server, so only if a yes to my first question
A chat protocol. Something like a Jabber client running on your client, and a Jabber server on your C++/Windows machine. Chat protocols allow almost realtime
While it may seem to make sense, I wouldn't use MSMQ in this scenario. You may not run into a problem now, but MSMQ messages are limited in size and you may eventually hit a wall because of this.
I would use TCP for this application, TCP is built with reliability in mind and you can simply feed data through a socket. You may have to figure out a very simple protocol yourself but it should be the best choice.
Unless you are using an embedded device that understands MSMQ out of the box, your best bet to use MSMQ would be to use a proxy and you are then still forced to play with TCP and possibly HTTP.
I do home automation that includes security cameras on my personal time and I use the .net micro framework and even if it did have MSMQ capabilities I still wouldn't use it.
I recommend that you look into MJPEG (Motion JPEG) which sounds exactly like what you would like to do.
http://www.codeproject.com/Articles/371955/Motion-JPEG-Streaming-Server