First of all, my apologies for the most likely inappropriate wording of the question. Not knowing exactly how to describe the problem I need to solve has been a major roadblock in my attempts to solve it.
I currently have a web server (Laravel) that needs to communicate with a SQL server in a different network, which only permits outgoing traffic. I made it work by having a C# daemon, running inside the SQL server's network, poll it for data and send it to the server through HTTP POST requests.
However, I now need the web server to communicate with the daemon. Something as simple as:
someone looks up a username on the web server
the server requests the daemon to look it up on the database
the daemon returns whatever information it found to the web server.
What I'm struggling with is finding the best way to do this.
All I need is for the server to be able to push requests to the daemon in real time. The daemon can reply through HTTP POST requests to the server, just like it is doing already. The best potential solution I have found is WebSockets, but it also sound like it might be overkill.
Am I missing something or are WebSockets indeed the way to go?
Guzzle is what I use to make HTTP requests to external APIs in Laravel.
Websockets are mostly used when the user has no control over the responses, for example, a chat window. But if you need to, for example, click a button and wait for the response Guzzle is enough.
Related
I am running an ASP.Net Web Forms application in an Azure Cloud. Now I have a special requirement that I have no idea how to solve: the server has to accept incoming connections over the internet from Android clients and then keep that connection open (or on standby) for a long period of time (days). So after hours or even days, the server has to find it's way to the Android client and send some data to it. I can use whatever technology works for both partners, but since the internet is in between, http/https is prefered as protocol (although WCF with TCP endpoints might also work when the connection is initiated by the client). The only thing I can think of is having the clients constantly poll the server if there is a command/data available, but that solution is ugly and wastes a lot of ressources. The client should react within seconds when the server has something to do for it, so I'd have to use a polling interval of ~10s. I know that http "keep alive" exists and can be utilizied in C# WebClients, but I doubt that it will work with my requirements? Is there any other possibility to achieve this?
Based on Niraj's response, I found Google Firebase Cloud Messaging. After that, I read up on the XMPP protocol and the SignalR technology available for .Net and finally decided to go with SignalR as it's implementation is most simple and does not require involvement of a 3rd party.
I am trying to use web sockets to allow two Windows services on different machines to pass data back and forth. Almost all the examples or information I have found are about using web sockets for Client/Server Side communication. I am having trouble figuring out how to set this up. I have considered using WebSocketHost as apart of Microsoft.ServiceModel.WebSockets, but then I am unsure how to bind it to a local port and not a URL.
Does any one have any suggestions
Thanks
I am trying to use web sockets to allow two Windows services on different machines to pass data back and forth.
You can open sockets on both machines using WebSockets as you found. The examples mention clients and servers because this is the typical usage, however the API really doesn't care. As long as each side has a listener and a sender they can communicate.
However I would like to mention that this isn't as simple as it sounds because both machines aren't always available. Sometimes one or the other is busy or the network is blocked or something else is going on, or the listener is too busy to respond right away, so you're going to end up needing some sort of queuing on both sides.
If you're doing a process based operation where one side tells the other "I want X" and it's a big operation like producing a document, I've found it much more resilient to build a queue in a database and toss the request in there, then wait for the other side to update the record to say it's done.
If they're smaller, faster requests, MSMQ would be more appropriate if you have it available.
However back to your original question, if you want to use it, any of the client-server examples should work just fine. The API doesn't care.
You can use SignalR Self-Host you really don't want to create your own WebSockets framework since this this will take a long time.
Here is a link on how to start a OWIN server in Windows services.
Hosting WebAPI using OWIN in a windows service
And how to set signalR in self host
Tutorial: SignalR Self-Host
You can accomplish this with Memory Mapped Files.
Inter-Process Communication with Memory-Mapped Files
I want to create a cross platform chat app with backend in c#
I searched for an approach to do so and found that I can do so with http requests to handlers on my server and use the response accordingly.
So till now I made the handlers which can add users, login, send and receive messages using database for storage.
Now I am making android client for that and to get messages for user I need to do http requests at a specific interval (3 seconds).
I feel it is not a good approach to do this. I am making this app for a target audience of nearly 30000. They would be able to chat one on one at a single session.
I just want to know if I am going in right direction or There is far more better ways to make chat apps using backend.
I have heard about wcf but I am not clear with what approach should I take. Please guide me about approaches for chat application.
Edit
An example of little working of any famous chat app like whats app, facebook messenger would be a great help.
Thanks.
You could do it with HTTP, but I'd suggest using TCP instead. There's a very solid base for a C# based TCP server on codereview right here which will outline how to deal with Socket objects how to handle connections properly.
The main perk of going about it this way is that you can connect your client to the server, and the client can be virtually any language, it doesn't have to be C# - as long as the language supports sockets, you'll be fine.
On top of that you can have the client listen to the server, which removes the need of polling the server for new messages every couple of seconds; the client socket will receive data when the server sends it, and you can handle it right away, nearly in real-time, whereas if you'd poll the server for new messages over HTTP every - say 3 seconds - you'll always end up with a delay in your chat service, which is something I think you will want to avoid.
See the code sample on CodeReview I linked above, and read up on how Sockets work in C#, how TCP works in terms of guarantees (TCP guarantees that whatever is sent over it will end up on the other side in the same order, but not necessarily in one packet, etc) and I'm pretty confident you'll be able to make a excellent chat app if you put it all to good use.
Edit: I just noticed the WCF tag on your post. I'd personally steer clear of it for this specific project since you want to achieve cross-platform support; try going as low-level as you possibly can for that.
I've some fishy application that makes HTTP requests to a website, i would like to intersect that request and send other data to the server. Is that possible in C#,java or C++?
EDIT: The application isn't mine, i just know the endpoint that it sends http requests
Fiddler might provide the functionality you need. At the very least it may enable you to see what is being sent to the web site.
in Java You can intercept request from Filter
You may want to look into using an HttpModule, whose purpose is to intercept incoming HTTP requests.
The ASP Column: HTTP Modules
Firstly are you aware of how it is connecting to the internet? For example, is it using the settings from Internet Explorer, or is it establishing a direct connection? If the latter, this may be tricky, there is no direct port forwarding as there in Linux, so you'll need some third-party tools to redirect the traffic to a server (which you can write in Java, C++ or C#, I would go for C# if you know it for pure speed of development) In that server you can intercept the request, and then create your own to actually send to the real destination.
Sounds like a cludge, but I think you're stuck with this approach due to the lack of direct port forwarding. You'll have to configure the third-party tool that you use to forward someother well known port to 80, and your server should write to this.
I am planning a SaaS system, to be written in C#, ASP.NET using WCF that has two separate components:
On a static IP web server in the cloud will be a web app, common to all clients.
Inside each client's office will be another app, installed on a server with IIS.
The site app will obviously be able to connect to the web services published on the web site. But here's the rub - I also want the web app to be able to initiate a connection to the site app... and the on-site server may not necessarily have a static IP. I can't control this, because we may have hundreds of clients at some point in the future, and we cannot limit our saleability by insisting that the customer has a server with fixed IP.
So, how to do this?
I could have the site apps "checking in" with the web every minute or so, to give the web app the possibility of responding with a "while you're here, please do x,y,z..." but that seems very inelegant. Also, if we're talking about hundreds of clients, I don't want to be bombarding my web server with all these "hi there!" messages if they're not actually required.
Is there a better way?
WCF? Here we go:
Use a message based approach (exchange message, no stateful method calls).
Clients connect to the server. Establish a HTTP-based TWO WAY CONNECTION. This way the server can call back to connected clients. This is standard WCF stuff and works well through NAT with version 4 of the .NET framework.
Voila. In case of a disconnect the client can re-connect, re-identify himself and gets the pending messages.
IIRC "push communication" is done by letting the client do a HTTP Request with an indefinate timeout. Then the server responds when he has something to say. After the respons the client immediately makes a new request.
It works out the same way like the server is making the connection and takes far less resources than polling.
Dynamic DNS is one possibility, but depends on your clients/customers.
If the site app is created by you, it only has to contact the web server when its address has changed (or when the site server/web app is restarted). Still, a keep-alive heart beat of, say, every 30 min. to 1 hour isn't a bad idea.
Edit: I think SNMP services may provide the answer but I'm not a networking expert. You'll have to do some digging or ask a separate question on stackoverflow.
What would you say about Comet technology?
Sounds like you'll definitely need some sort of registry on the server, then it could attempt to call out to the client apps if it needs work doing.
Generally it is client apps that check in with the server every X seconds - this is how Selenium grid works anyway. With a central hub with which clients register. When the hub receives a request to run some tests it passes the jobs out to the clients to perform.
You may not need the "checking in". The server could just attempt to call out to a registered client app until it finds one that is available.This way only the server would need a static address (could use a DNS name instead of an IP to make it more robust).
Also have a look at XMPP PubSub. This could be a more robust and standardised way to handle this.
In the end I decided to go with NetTcpBinding, for reasons best given by #Allon Guralnek here. It's worth clicking through and reading what he has to say...