I have a .NET application which sends PHP GET and POST requests to my server (on an AWS EC-2 instance).
I now have a need for the local application to know in real-time when an event on the server happens.
Basically two "accounts" are linked and they need to synchronize, so when one makes a change on the server, then the server must send a signal to the other to update it's "view".
I'm aware that I could achieve this by constantly querying to server to check for changes, but that seems horrendous.
Could someone please point in the right direction here?
Thanks!
Certainly you could use signalR, signalR can be hosted like website, when your client starts it can connect to this signalR website. SiganlR should be hosted separately from your server application.
Let say A,B client and your Server application got connected to signalR. Now when A modifies something using post method to your PHP server, PHP server then can invoke a method in signalR , then signalR can broadcast message to all the clients connected. You can use group concept in signalR to target specific audience.
Related
So I'm starting with the simple Greeter service from the VS2022 sample project template "ASP.NET Core gRPC Service", targeting .NET7, running on Windows. Name this side "A".
I was able to write a second console app (also .NET7) that connects as a gRPC client to that service, invoke the SayHello() rpc successfully and retrieve the expected response message. Name this side "B". So far, so good.
My scenario, however, is a bit different: I want the client B to connect to the server A and authenticate with the server (which is not part of the sample so far but I assume this will work fine as well). Then, the server A shall start acting as a gRPC client and the console-app-client B shall act as a gRPC server, i.e. I want them to switch roles (or establish another role if you like). The challenge is that I want the two parties to re-use the same TCP HTTP/2 connection that has already been established. So I'm looking for a way to create new instances of gRPC client/servers at runtime and provide them with the existing TCP connection. The reason why I need to do it this way are limitations coming from network security (the initial connection can only come B to A). I'm aware that by using streams I can make my server A send messages to B, but I'd prefer to have the full client/server support.
I saw a few discussions around the same question but the presented approaches are using GO as a language and it's hard for me to understand whether and how I can do the same in .NET7.
Possible? Thanks!
There is a solution of 3 projects (client (.NET WPF), server (ASP.NET Core gRPC (will run as a Windows service)), agent (.NET Console application (runs on the same PC as the server, but in user session)).
The server must have 2 separate services (one that communicates with the remote client and one that communicates with the local agent).
When a client's request is received, the server "forwards" it to the agent, the latter executes the request and returns the answer to the server, and then the server sends this answer to the client that asked for it.
Is it possible to implement this? And if so, how? I don't understand it at all...
P.S: I need it for the client to get screenshots from the server, but since the server is a Windows service, it cannot take those screenshots. The idea is that if the client asks the server to "ask" the agent to take a screenshot and send it to him, then the server will send the screenshot to the client.
Client-server (bidirectional streaming)
Agent-server (bidirectional streaming)
The flow you are describing is fairly straight-forward and is similar to how HTTP proxies proxy browser requests.
Run the snippet below you will see the flow I'm describing where the client makes a request to the server, the server then forwards the request on to the agent. The agent then responds to the request from the server using the same connection as the request from the server, and the server responds to the client using the same connection the client sent the request over.
My client sends messages to the my server using tcp protocol (my server has a listener).
I'm trying to send messages back from the server to the client, but I'm not sure what do I need to add to the client in order to get those messages.
I tried looking it up, but I didn't understand how to implement it.
Could you please assist?
It's the exact same process, but in reverse.
If you intend to receive messages independently (i.e. not in response to a request by the client), you need to make the client a TCP server, too. The client needs to implement exactly the same thing as the server you have now and the server needs to connect to the client.
Can't you use WCF, which supports callback contracts?
If you want a console example of a client server application using a network library see here http://www.networkcomms.net/how-to-create-a-client-server-application-in-minutes/.
If you want a WPF application example then see here http://www.networkcomms.net/creating-a-wpf-chat-client-server-application/
I want to build a web-based irc client with JQuery. I know I need to open a socket to the irc server. What I'm wondering is, is it possible to open a socket purely from server-side C# code? Or would the nature of a web application prevent this and I would have to write a service to run on the host machine?
Thanks for any help :)
Yes, you should be able to make a socket connection from server-side ASP.NET code. On the other hand, given that you'd presumably want a persistent connection to the IRC server (rather than a new one on every request), you may want to write a separate service anyway - you don't want ASP.NET recycling to kick in and wipe all your context, for example.
Your ASP.NET code could then talk to your service to find out what had happened since the last request for that user, etc.
One simple approach would be to setup a singleton WCF service which acts as the bridge to IRC. jQuery AJAX calls against that service could then post messages that were input by the user, as well as retrieve messages sent by other users.
I have implement the chat with ASP.Net by using the SingnalR for duplex communication.
What I really done consist on the following steps.
1) ChatHub.cs
I have write down all the logic to connect with the IRC server and connect to the channels, receive different messages and notification from the IRC server. I then send these notifications to my ChatHub client by calling the javascript call backs from the ChatHub.cs
2) Client.aspx
Simple HTML page and it is using jquery to register the callbacks from the ChatHub.cs
3) IRCDotNet.dll
I have used this library to communicate with the IRC Server.
Hope, It will help somebody. Here is the link to download the IRCDotNet.dll
http://ircdotnet.codeplex.com/releases/view/50639
This topic has been discussed million times before, but let me clarify my needs:
I need a single server which controls a system and includes the necessary functions. Furthermore, there will be "n" Clients which represents only the HI/GUI and call server side functions. The server itself should be able to send data back to the clients and call client-side functions too (like shutdown, exit and so on...)
I have heard about duplex services/contracts (http://msdn.microsoft.com/en-us/library/ms731064.aspx), but I'm not sure how far I'll come with that.
How would you handle this?
I recently made a proof of concept app that made both the server and the client host a WCF service each. The client connects to the server and then in a handshake call, gives the server the connection information to allow the server create a separate connection back to the client. It worked a treat with multiple clients on network links from local lan to 64k line on remote sites at the same time.
You could use WCF, and host the service on the server in IIS, in the application on the client and let the client register it's endpoint on the server.