Is there any way to call a method / function in an API rest in C# if it is a specific time without any request?
The goal would be to know when a person would have left the interface prematurely (or in case of power failure).
Or in case of prolonged inactivity.
In my case : the front is in angular4
In other words, you tring to achive the ability to commuincate with the client from the server.
It's called WebSockets, there are some implimation for that.
The best implantation for C# WebSockets is SignalR
The way you should use it' is that in your server you would 'ping' all your connected clients, and those who are not responding, assume as disconnected (you might add some delay to prevent unwanted disconnections)
The second option, is to created an interval on your client, and each time send an 'ping' to the server that the client 'is alive', that's pretty messy and i don't like that approach, but its little bit easier.
Good Luck!
Related
I need a way for clients (C# applications) of a ASP.NET Web API to be notified of certain changes via the Web API. They don't even need to know what the changes are, just need to get a notification that something changed (at that point it's up to the client to call the API to get any specific data they may need after getting the notification). I'm not sure what a good way of accomplishing this would look like.
I'm thinking one way might be to create events and somehow have the client subscribe to those events, but I don't know how to do that through Web API.
I found some mentions of SignalR on Google, but this seems like a lot of work to implement and seems to do a lot more than I need.
All I need is for the Web API to be able to tell the client "something changed, come and get it". However, I want to avoid polling. What is the fastest/easiest way to do accomplish this?
You really have only two options:
Use SignalR or any kind of Websocket framework.
Have the client apps poll the API to look for changes.
Web API is stateless by design. The API doesn't maintain any kind of connection or state information with any of the client applications. Therefore there's really no way to implement anything like a traditional C# event.
SignalR would be the coolest way to do it ;)
But the simplest thing to do is just poll server once every X and ask 'Did anything change?'.
3 years later..and there is one more option that looks very promising which is WebHooks
Polling
SignalR (Server<->Server, Server<->Browser)
WebHooks (Server<->Server)
Difference between SignalR and WebHooks
I think that SignalR is for bidirectional communication between client and server. For an SSE (Server sent Event) use PushStreamContent instead. https://techblog.dorogin.com/server-sent-event-aspnet-core-a42dc9b9ffa9
Google firebase can also be used for this. You can write firebase code in your client application(javascript or mobile app etc.) which can be triggered whenever any change occurs on firebase.
So whenever something happens on your server hit the firebase url and that will raise the event which can be caught on the client side.
May be it can help.
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'm designing a client-server architecture which is implemented using Windows Communication Foundation. In one of the use cases, the server needs to request the status of the client(s), which means it needs to call the SendStatus() method on the client and ask for its status. I was just wondering if this use case can be implemented using WCF, without creating a standalone service on the client side. I'm trying to avoid sockets because the client is a background service and is essentially always connected to the server. I understand that WCF eventually uses sockets for communication, but I'm specifically trying to use WCF since this is more like a proof of concept.
A workaround I thought of was that the client could call the SendClientStatus() method on the server and send its status every 5 seconds or so. But then again this doesn't seem like a good approach. Any help would be appreciated.
In the world of WCF, you have more or less two options.
A) A Duplex service with Dual Http Binding
B) A no-return-value polling scheme - this is essentially what you described. The naive implementation, as you correctly note, is not that great, but there are optimizations. Since you do not need anything returned from SendClientStatus (correct?) , you can optimize the communication by only sending an update when there is one - e.g. as long as the status of the client remains the same, nothing is sent to the server. Depending on the frequency with which client status changes, this can greatly reduce the traffic. Duplex services present some extra configuration you want to avoid unless you really need them.
I have 50+ kiosk style computers that I want to be able to get a status update, from a single computer, on demand as opposed to an interval. These computers are on a LAN in respect to the computer requesting the status.
I researched WCF however it looks like I'll need IIS installed and I would rather not install IIS on 50+ Windows XP boxes -- so I think that eliminates using a webservice unless it's possible to have a WinForm host a webservice?
I also researched using System.Net.Sockets and even got a barely functional prototype going however I feel I'm not skilled enough to make it a solid and reliable system. Given this path, I would need to learn more about socket programming and threading.
These boxes are running .NET 3.5 SP1, so I have complete flexibility in the .NET version however I'd like to stick to C#.
What is the best way to implement this? Should I just bite the bullet and learn Sockets more or does .NET have a better way of handling this?
edit:
I was going to go with a two way communication until I realized that all I needed was a one way communication.
edit 2:
I was avoiding the traditional server/client and going with an inverse because I wanted to avoid consuming too much bandwidth and wasn't sure what kind of overhead I was talking about. I was also hoping to have more control of the individual kiosks. After looking at it, I think I can still have that with WCF and connect by IP (which I wasn't aware I could connect by IP, I was thinking I would have to add 50 webservices or something).
WCF does not have to be hosted within IIS, it can be hosted within your Winform, as a console application or as windows service.
You can have each computer host its service within the winform, and write a program in your own computer to call each computer's service to get the status information.
Another way of doing it is to host one service in your own computer, and make the 50+ computers to call the service once their status were updated, you can use a database for the service to persist the status data of each node within the network. This option is easier to maintain and scalable.
P.S.
WCF aims to replace .net remoting, the alternatives can be net.tcp binding or net.pipe
Unless you have plans to scale this to several thousand clients I don't think WCF performance will even be a fringe issue. You can easily host WCF services from windows services or Winforms applications, and you'll find getting something working with WCF will be fairly simple once you get the key concepts.
I've deployed something similar with around 100-150 clients with great success.
There's plenty of resources out on the web to get you started - here's one to get you going:
http://msdn.microsoft.com/en-us/library/aa480190.aspx
Whether you use a web service or WCF on your central server, you only need to install and configure IIS on the server (and not on the 50+ clients).
What you're trying to do is a little unclear from the question, but if the clients need to call the server (to get a server status, for example), then they just call a method on the webservice running on the server.
If instead you need to have the server call the clients from time to time, then you'll need to have each client call a sign-in method on the server webservice each time the client starts up. The sign-in method would take a delegate method from the client as a parameter. The server would then call this delegate when it needed information from the client.
Setting up each client with its own web service would represent an inversion of the traditional (one server, multiple clients) client/server architecture, and as you've already noted this would be impractical.
Do not use remoting.
If you want robustness and scalability you end up ruling out everything but what are essentially stateless remote procedure calls. Since this is exactly the capability of web services, and web services are simpler and easier to build, remoting is an essentially pointless technology.
Callbacks with remote delegates are on the performance/reliability forbidden list, so if you were thinking of using remoting for that, think again.
Use web services.
I know you don't want to be polling, but I don't think you need to. Since you say all your units are on a single network segment then I suggest UDP for broadcast change notifications, essentially setting a dirty flag, and allowing the application to (re-)fetch on demand. It's still not reliable but it's easy and very fast because it's broadcast.
As others have said you don't need IIS, you can self-host. See ServiceHost class for details on how to do this.
I'd suggest using .NET Remoting. It's quite easy to implement and doesn't require anything else.
For me its is better to learn networking.. or the manual way of socket communication.. web services are mush slower because it contains metadata..
your clients and the servers can transform to multithreaded application. just imitate the request and response architecture. it is much easy to implement a network application like this..
If you just need a status update, you can use much simpler solution, such as simple tcp server/client messaging or like orrsella said, remoting. WCF is kinda overkill here.
One note though, if all your 50+ kiosk is connected via internet, then you might need use VPN or have an open port on each kiosk(which is a security risk) so that your server can retrieve status update from each kiosk.
We had a similiar situation, but the status is send to our server periodically, so we only have 1 port to protect/secure. The frequency of the update is configurable as to accomodate slower clients.
As someone who implemented something like this with over 500+ clients and growing:
Message Queing is the way to go.
We have gone from an internal developed TCP server and client to WCF polling and ended up with Message queing. It's the only guaranteed way to get data to and from clients and servers over the internet. As a bonus, many of these solutions have an extensive framework makeing it trivial to implement publish-subscribe, Send-one-way, point-to-point sending, Request-reply. Some of these are possible with WCF but it will involve crying, shouting, whimpering and long nights not to mention gallons of coffee.
A couple of important remarks:
Letting a process poll the clients instead of the other way around = Bad idea.. it is not scalable at all and you will soon be running in to trouble when the process is take too long to complete.. Not to mention having to handle all the ip addresses ( do you have access to all clients on the required ports ? What happpens when the ip changes etc..)
what we have done: The clients sends status updates to a central message queue on a regular interval ( you can easily implement live updates in the UI), it also listens on it's own queue for a GetStatusRequest message. if it receives this, it answers ( has a timeout).. this way, we can see overal status of all clients at all times and get a specific status of a specific client when needed.
Concerning bandwidth: kiosk usually show images/video etc.. 1Kb or less status messages will not be the big overhead.
I CANNOT stress enough that the current design you present will have a very intensive development cycle AND will not scale or extend well ( trust me, we have learned this lesson). Next to this, building a good client/server protocol for this type of stuff is a hard job that will be totally useless afterwards if you make a design error ( migrating a protocol is not easy)
We have built our solution ontop of ActiveMQ ( using NMS library c#) and are currently extending Simple Service Bus for our internal workings.
We only use WCF for the communication between our winforms app and the centralized service(s)
I’m writing a prototype WCF enabled distributed app, to try and find out any issues I’ll have upgrading my existing “sending xml over tcp to communicate” apps I’ve got. I’m using Callback Contracts to register clients with a server (Singleton in ServiceHost) and so far all the communications between client and server work. I can connect multiple clients to the server and send a broadcast from the server that is received by all clients. I can block a particular client and the other clients still receive the calls. This is good.
To continue my learning and evaluation of performance I would like the client to record what time the server sends each message, as well as what time the client receives that same message. How should I best go about this?
Is there something similar to SOAP extensions, where I can add to the outgoing from the server and incoming to the client? Or would I need to add a “timeSent” parameter to every method that the server calls on the client and record the time received on the client (yuck!)? Is there a better way to accomplish this?
I am using net.tcp rather than wsDualHttpBinding (which also works but is less performant).
Hmmm... that's a difficult one. The problem here is you can't even make sure both the client and the server timers are in sync.
If what you want to do is send some out-of-band data, so that you don't need to modify your methods, you can use the method suggested here. I think it should be enough.
David is right about the problems with clock synchronization. However, adding the timestamp information outside of the service/client implementation is not hard at all on WCF.
You're right it doesn't support SoapExtensions, though, in fact, it has a much richer set of extensibility point. In your specific case, I think a custom behavior that adds a MessageInspector would probably work.
There are actually two message inspector interfaces: One for the client (IClientMessageInspector), and one for the server (IDispatchMessageInspector).
The easiest way to hook up a dispatch inspector on the service side is through a service behavior (IServiceBehavior), since you can hook that up to your service implementation as a custom attribute. Here's a simple example of how to do it. You can also hook it up through an IEndpointBehavior, but you need to do that either through code when setting up the service host or through configuration, which requires writing a bit more code.
On the client side, you still use an endpoint behavior, but introducing those through code is a lot easier since you have direct access to the ClientRuntime from the proxy client.
Anyway, I would think that something like a timestamp is better added to the message as a custom header so that it is not part directly of the message payload.