is it possible or recommended to use any XMPP Clients to send & receive messages with ASP.NET? I have a AWS EC2 Micro Instance, Azure Webrole Small Instances and another Small Instance reserved for websites. I have tried to achieve this with ASP.NET & Jabber-Net but couldn't make it work. I don't want to receive the messages on any JS clients; I want to process the messages on the server itself.
Thanks in advance...
This is no problem. We have done similar stuff before. You can create as many persistent XMPP sessions as you need on behalf of your users for sending and receiving xmpp stanzas.
The only problems we have seen are security restrictions for IIS on many web hosters which don't allow you to create sockets.
see also:
http://msdn.microsoft.com/en-us/library/330a99hc(v=vs.100).aspx
http://msdn.microsoft.com/en-us/library/ff649312.aspx
Related
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
When using java APNs, if using the same program to send messages to different applications, it is required to use different certificates. Does switching certificates causes disconnection/reconnection and is it considered a bad practice? (as APNs would like to have persistent connections thus preventing denial of service).
I don't think it's possible to switch a certificate for an existing connection. At least I'm quite sure it's not possible in Java SSLSocket (since it is constructed by an SSLSocketFactory, and you use the certificate in one of the parameters required for constructing that factory).
You should maintain an open socket for each application you are sending notifications to. This way you don't have to close the socket and open a new one each time you need to switch certificates.
I need to put and get messages to/from our remote MSMQ, but because we will do the put s from our mainframe, we need a way that can be implemented in COBOL(or PL/1 maybe). My questions are;
1) Is it possible to enable HTTP GET/POST requests to put/get messages without WCF implementations? That is, we need to be simply able to make requests as in
http://our_server:port/msmq/queue1?operation=put&message=test_message&...
2) Is there any other way to access and put messages into MSMQ from mainframe?
Any suggestions will be appreciated
Thanks in advance
EDIT
I think I couldn' t tell what I want exactly. I have data on mainframe and I want to put these data into a MSMQ which is running on a Windows machine. IBM WebsphereMQ has WebSphere MQ bridge for HTTP so that it accepts HTTP requests and puts the requests' payload into queue. Does MSMQ have such a feature?
Thanks again :)
You can use the EZAPI interface programs to manage the traffic natively in your COBOL programs or use one of the many variants of MSMQ to WebsphereMQ or JMS.
The EZAPI stuff will let you do the direct http puts, but you will need to manage it all.
Why not just hook the MSMQ into whatever queueing software you have on the mainframe and make it work the way it was intended?
If your mainframe applications are running in CICS, then HTTP client requests are just API calls. Where I work, we've been doing this in COBOL applications since 2006.
All that I know of are HTTP GET and POST requests.
On our school servers, we can play some games but not others. It seems that we cannot play any games where there is real-time information. So I'm thinking that real-time information requires a different method for the game to communicate with the server, and this method is blocked.
What other ways are there for webpages to communicate with servers?
Using GET/PUT requests is the old-school way to communicate with a webserver. Once a webpage has been loaded, it can use Java/Flash applets, AJAX, or WebSockets to communicate with the webserver over a separate connection without having to leaving the current page. This allows for bidirectional communication and real-time updating of the webpage content.
First of all thanks for taking the time to read my question. Here is what I am trying to accomplish followed by what I have so far on this.
What I want to do is create a Windows application (or server of sorts) that would listen for requests from an ASP.NET application. The windows application would be installed and would listen for messages from ASP.NET application and then do some processing. The flow is like this:
A user downloads the desktop application and registers their IP address on my web site. After downloading the desktop app, the ASP.NET application can then send requests to that particular desktop client for further processing. I think further processing is independent of the resolution in this case that's why i have skipped over details on what processing would be done. But if you think it is important, please let me know and I will add those details as well.
I have looked into creating a TCP server that would listen for requests. Because the user has already registered their IP address on my web site, my web site assigns them a unique identifier and stores the ID alongwith IP address in database. Now, the ASP.NET site can send requests to that desktop application.
I have looked into creating a TCP server for this purpose. While researching I also came across PNRP and it seems something like what I am trying to do.
Can you guys recommend some solutions or where I should be looking at for this scenario? Should I create a simple TCPLISTENER or may be go with PNRP approach? Or something else?
The basic requirement is for a web application to be able to communicate with a desktop application. The web application would be servicing numerous users and each user would have a desktop application installed. Which user for which desktop client question would be addressed by the web application that would maintain a database of unique user id's and their corresponding IP Address.
Thanks in advance for your help.
You could use .NET remoting or a web-service in the desktop app. Use WCF or WSE for the latter. You can use COM to add windows firwall rules.
Whatever you do, take firewalling/NAT into account. It might be easier for the client application to poll the server (initiate the connection) otherwise you open a can of worms by trying to have a remotely-accessible server in your user's computer without having to do some very manual configurations on the user's networking equipment.
Once you have that part sorted out, what I used in your situation was .NET Remoting. At the time WCF had not come out and when it did it was to crippled for my needs. TCP IP sockets were too raw (I had to write too much code) and so Remoting solved my problem ideally (a hand full lines of code to set up the connection, and everything was automatic from there on).
EDIT: I use an excellent third party library that makes Remoting even more flexible (flexible enough that I am still waiting for WCF to catch up with the featureset so that I stop using Remoting, and no luck yet!). Check out http://www.genuinechannels.com/ to see all the features they have. It includes making calls from server to client, and that sounds exactly like what you need to do. Check it out.