Theory: Azure Websockets - c#

Is it possible to consume an external (to Azure) API that requires you to establish a wss connection to receive notifications of changes in some kind of Azure container (Kubernetes/Durable Function)?
Or do I need to run a Virtual Machine with a background service keeping the socket alive until it's got no more data to send (hours). No UI.
https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview?tabs=csharp
Durable functions look promising but I'm unsure if these will cover my requirements.
Any advice welcomed.

Yes, you should be able to use WebSocket connections to services deployed on Kubernetes. And also the other way around where services in Kubernetes is WebSocket clients with connections to external services.

I haven't tested, but Azure Web App supports Web Socket. As you can host Azure Functions in the same App Service which is running your web app, I think it's possible to support web sockets on your functions with durable function.
Another point that leads me to think this, is the native support of Azure Functions to SignalR Service, which runs on Web Socket too.

Related

How to communicate from Azure web app to WCF services hosted locally in IIS?

I have an ASP.NET MVC application hosted in Azure.
This application is complemented with a desktop application that also has WCF services for communicating with III party interfaces. WCF are hosted locally.
There are thousands of clients using the desktop application at different geographical locations.
Till now, every desktop application used to talk to web app using api with the help of WCF.
This was limited to on demand from the desktop application.
Whenever desktop application feels the need to talk to web app, it used the way of web api from WCF.
Now, what I want is:-
To access the different desktop applications(typically called sites), from azure depending upon the need.
This is required on account of an online ordering system that is through web app/mobile app.
I do not want to keep polling from desktop application to know about if any new order is there for this site.
I feel it would be better if I can play from other side.
Also, keeping in mind that IP of sites will not be fixed. There may be issue with firewall. NAT may translate resource identifier differently.
Can service bus in azure may be of any help, but what confuses me is that every desktop application is having its own WCF service and order should reach the respective site only.
Any type of ideas on this would be appreciated.
According to your description, Service Bus messaging is a perfect way to achieve this.
More information about Service Bus Messaging, we can refer to: Service Bus queues, topics, and subscriptions
In addition, We can also use RabbitMQ or ZeroMQ which is similar with Service Bus Messaging because both of them are free. You can choose an best way to realize your requirements.
About differences between ZeroMQ and RabbitMQ:
ZeroMQ has better performance, but it is built in the case of allowing message data loss to apply to high throughput / low latency applications. Unlike ZeroMQ, RabbitMQ fully implements the AMQP protocol, which is similar to mailbox services, supporting message persistence, transaction, congestion control, load balancing and so on, making RabbitMQ have a more extensive application scenario.
Function RabbitMQ ZeroMQ
Message persistence Support Not Support
Transaction Support Not Support
performance Low High
stability High Low
Support for AMQP protocol Support Not Support
Application scenario Data loss is not allowed High throughput
More information about RabbitMQ and ZeroMQ, we can refer to:
RabbitMQ
ZeroMQ
If you are able to modify the desktop applications, implementing a websockets connection with SignalR might be worth a look. The desktop applications sign up with a SignalR hub you provide.
You can then push data to the clients from, for example an ASP.NET MVC app. It works very reliable and handles lots of connections well. It is typically used for realtime web communication but might be useful in your case, too.
The downside is probably, that the desktop app needs to initially sign up to a hub to receive push messages.

turning a windows service into a web app core service?

I have a windows service which allows incoming and outgoing connections to a UDP port that is using Lidgren UDP networking library.
I've been really wanting to change this to use .net core for some of the obvious cross platform benefits and other benefits like deployment and scaling within Microsoft's Azure Cloud.
It seems the only easy way to do this is to use the Web Core app which is not really what im doing(Its not handling http requests).
I've done tons of googling to figure out how to handle this situation and the only thing i have found is a library called WindowsService for .net core but that just allows me to convert a 462 app to .net core and continue using windows service which is not ideal.
TLDR; Can anyone shed some light on how i can convert a windows service which is handling UDP Traffic into a deployable application for azure?
I've been really wanting to change this to use .net core for some of the obvious cross platform benefits
Before changing to .NET Core, you need to confirm whether all the dependent assemblies support .NET Core.
Can anyone shed some light on how i can convert a windows service which is handling UDP Traffic into a deployable application for azure?
There are multi services which support windows service on Azure. Based on your description, you could choose Azure VM scale sets, Azure Cloud Service and Azure Service Fabric to host your windows service. All of these services could listen on an UDP port to get/send a message from/to client.
You don't need to modify your code if you choose Azure VM scale sets. You can also package your Windows Service to a executable file and deploy it to Cloud Service or Service Fabric. You could also check following document to check the differences between Cloud Service and Service Fabric.

How do I push data from a console program over SignalR websockets?

I have a website running as an Azure Web App which is configured to use SignalR and the Azure Service Bus scaleout backplane. All working well, and clients connect via the /signalr URL and I can push data from the server to the connected clients.
I also have several console apps which periodically run and output new data. I would also like to push the new data to the web-connected clients.
How can I tie in my non-web applications with SignalR? All the examples I see assume every server in the scaleout cluster are web-facing. Is there some special setup I need to do to have external processes join the SignalR cluster and be able to push data to web-connected clients over the SignalR websocket connection without having to make them web apps as well?
There are two options.
First Option
You can connect your "console apps" to the signalR backplane, and these apps will be able to call client's methods with something like
var hub = GlobalHost.ConnectionManager.GetHubContext<MyHub>();
hub.Clients.All.doSomething("blah-blah");
You can use any port for the signalR config but same backplane configuration and same Hubs. You can use Owin for self hosting. Nobody will connect to these console apps.
Disadvantages:
1) Your console applications needs to reference SignalR.SelfHosting and your hubs classes. This is not good from architecture point of view.
2) Your console apps will listen some ports (since they're signalR servers). Theoretically somebody could connect to this hubs and do something. This is not good neither from architecture point of view no from security.
Second Option
You can implement Hub method like "PushSomeDataToClients" and call it from your console apps using SignalR client as mentioned in #bartbje comment.
Pros: no disadvantages from the first option.
Cons: You need to implement some security stuff to prevent anybody outside the system to call this method. SignalR has a lot of stuff to do this, so just google. For example you can create separate Hub for inter-system communications.
Third Option
Interact with web-server apps with another way then SignalR. Probably you're already using something like rabbitMq or any type of service bus. Also you can implement it using separate ApiController at your web-server app. But it seems to be closer to the second option.
Due to me, I would probably choose the third option since it's clean from architecture point of view.

What are some known ways to push data from web api to a windows form client

I'm having trouble finding some documentation or services available to help push data to clients on winforms. (Maybe my search query sucks)
Ex.
I open an application on my phone which sends a request to a web api controller to run some code in a windows form app that is already running somewhere else. (for example, my PC)
I can find an abundance of information on Azure Notifications Hub and push messaging when it comes to mobile devices and windows store 8 apps but not for plain old winforms app.
I am aware I can create a que on a db and poll it with clients but want to see if there is a way to avoid polling scenarios.
What are some known ways to push data from web api to a windows form client?
Learn About ASP.NET SignalR
ASP.NET SignalR is a new library for ASP.NET developers that makes
developing real-time web functionality easy. SignalR allows
bi-directional communication between server and client. Servers can
now push content to connected clients instantly as it becomes
available. SignalR supports Web Sockets, and falls back to other
compatible techniques for older browsers. SignalR includes APIs for
connection management (for instance, connect and disconnect events),
grouping connections, and authorization.
Here is a sample in the topic area.
Using SignalR in WinForms and WPF
Implementing SignalR in Desktop Applications
ASP.NET SignalR Hubs API Guide - .NET Client (C#)
This document provides an introduction to using the Hubs API for
SignalR version 2 in .NET clients, such as Windows Store (WinRT), WPF,
Silverlight, and console applications.
The SignalR Hubs API enables you to make remote procedure calls (RPCs)
from a server to connected clients and from clients to the server. In
server code, you define methods that can be called by clients, and you
call methods that run on the client. In client code, you define
methods that can be called from the server, and you call methods that
run on the server. SignalR takes care of all of the client-to-server
plumbing for you.

How to communicate from Azure webjob to Azure webapp?

I'm running an Azure webjob alongside an Azure webapp. The job runs periodically and the result of the job is needed in the webapp. How do I get the result there?
I tried with a WCF netNamedPipeBinding but since there are no startup tasks for Azure webapps I cannot add a net.pipe binding to the IIS website nor can I enable the net.pipe protocol.
I have it working now with a basicHttpBinding but this binding is exposed to the entire internet which I absolutely do not want. I simply want machine-local communication between a webjob and webapp running on the same machine.
CORRECTION: I thought I had it working on Azure but that is not the case. When running on Azure I get an error from the webjob: An attempt was made to access a socket in a way forbidden by its access permissions 127.0.0.1:80 (using basicHttpBinding). Probably the webapp has an internal port number I don't know.
You have a few options:
Use the file system to pass messages
Use Azure Storage Queues to pass messages between the two
Use Azure Service Bus Queue to pass messages
Use any shared storage (database, Azure Storage, etc) to pass messages
The benefit of all these approaches is that it makes your message passing async and thus more resilient to one of the two services (web app or web job) going down for some time.
You can use the file-system to communicate between the WebJob and the Websites.
It is shared between them and between all of your instances.
Simply write a file from the WebJob and use a file system watcher in your webapp to recognize when a file is created or changed.
Note you cannot communicate through localhost in Azure Websites (or WebJobs) and cannot listen on a port that is not 80/443.
You can use azure service bus queue, then point your service (web app) to consume messages from queue.
The closest answer is to set WEBSITE_DISABLE_SCM_SEPARATION=true in App Settings. This will enable WebApp and SCM processes work in same sandbox. Unfortunately this option is deprecated by Azure and no longer supported. Thanks all for attempting the answer. More information can be found here.

Categories

Resources