I want to consume the API messages in c#.net and the response it may come continuously/frequently. Team suggest me to use Web sockets. But I consume the API thru HTTP. Can any one give idea which is better and advantages of Web-socket in continuous receiving the messages as well as in HTTP
HTTP normally uses a request/response model. It does not allow the server to send data to the client, unless the client first requested it. This can be worked around by letting the client regularly poll the server, or by using the long polling technique where the server delays the response until data is available. In both cases, the client will need to regularly make a new request (though less often with long polling).
Web sockets remove these limitations so that polling or long polling is no longer needed.
You may try with ASP.NET SignalR which able to send and receive messages via HTTP. You can achieve real-time web functionality to your messaging application. It's able to have server code push content to connected clients instantly, rather than having the server wait for a client to request new data.
Have a look at these samples -> http://www.asp.net/signalr/overview/getting-started/tutorial-getting-started-with-signalr
Related
Here’s our architecture:
JIRA webhook sends messages to a Java Jersey REST service when issues are assigned.
C# client application registers the username/host machine combo with the Java web service when a user logs into the machine
When the web service receives a message from JIRA, it finds the assignee username and sends the required data to the C# client app on the host machine(s) the user is logged into.
I’ve thought of a couple approaches to solve the web service to client message.
My first is opening a TCP port on the client and having the service send each message directly to it. This is the most straight-forward approach but makes the client a little heavy in that it maintains the list of user assigned ticket data that they can then manipulate (acknowledge or remove).
The other is having the service maintain the data model and the client requests data periodically. This makes the client simpler but then I’d have to implement a polling interval to grab data, and add some POST methods for acknowledging and removing data from the user’s list.
I was looking into different ways to have the client register a channel with the service, like ServiceStackEvents, but I can’t see a way to make that work with a C# client and Java service. Something like that would be perfect. A way for the service to send callbacks or event messages to a client based on a user filter.
If someone has some suggestions or knows of an API to help with this, please post a link so I can dig into it. The POSTs are all working swimmingly, it’s just getting the data back to the clients that I’m struggling with the best approach.
Thanks!
Client polling is not a terrible solution.
But if you want a firewall and proxy friendly duplex protocol, check out WebSockets https://en.m.wikipedia.org/wiki/WebSocket.
So I have a .NET project and my goal is to send an event to a specific user from the server. This event of course will have all kind of information, the ideal way would be for it to be similar to the REST requests from client/server... But I can't think my way through it. I've heard terms like sockets and stuff and someone told me that I could do it with a system similar to message system but can't find anything about it. Here is a conceptual example
I would recommend you checking out SignalR which is a protocol-wrapper over port 80 (the one browsers and web traffic uses). This way you can have the server send stuff to the client whenever the server wants. The more basic approach is to let the client poll the client (send a GET/POST-request) in intervals (~once a second) and return your information in the poll request response.
I have a requirement to return streamed response from WCF service.
The client would call GET on WCF REST URI and the server would send XML response when available. If no response is available, server would send a dummy XML response every few seconds to keep the connection alive.
I know this should ideally be done using Signal R (WebSockets) but I would like to know if there is a way to achieve this in WCF (without using Signal R).
I don't have to return large data, I would like to send intermittent small sized XML data.
Let me know if someone has achieved something like this with WCF REST?
I am not sure how flexible you are by using WebAPI, sorry if its not what you want, but I came across this code below which is basically an api controller that pushes data back to the client on a continuous basis as HTTP response..
The client is basically a HttpClient which connects to a Uri address issuing a GET HttpRequestMessage. The message is sent with SendAsync and the stream is received as response.Content.ReadAsStreamAsync()...
Here is the link: http://aspnet.codeplex.com/SourceControl/changeset/view/bb167f0b0013#Samples/Net4/CS/WebApi/PushContentControllerSample/PushContentController/Controllers/PushContentController.cs
The best way to create a persistent connection between server and client is to use WebSockets.
WCF can use WebSockets via the NetHttpBinding.
Once configured, you can force communication to always be over WebSockets via:
transportUsage=Always
Since you have a persistent connection, you will need to use callbacks to manage application flow when data is sent across.
There's also a detailed article here describing a few different ways to create WebSocket connections in .NET (without SignalR).
Create a WCF Service that Communicates over WebSockets
I am looking for an open-source framework that can handle communication between my backend host and a WPF frontend client. The following are points I need to consider:
Client is a WPF desktop app, host is a C# console APP but can also run as Windows Service
Host can accept connection requests, client connects, but I still seek bi-direction communication capabilities.
The client and host are not in the same network (need to send messages over the internet)
Just one (possibly more but less than 10) client will connect to the host.
I like to be able to handle the following communication patterns: One-way message, two-way request/response, and streaming from host to client.
The content will consist of serialized POCOs/DTOs and serialized time series data. Each serialized DTO will be of approximately size 400 bytes, the serialized time series can be a lot larger, potentially several megabytes.
Some messages will be sent scheduled, meaning for example, the host sends a new DTO every second. (if the framework includes such scheduling mechanism then even better)
I like to be able to stream data to the client, such as a client that receives and then updates data on its GUI in real-time.
My question is: What might be the best C# based framework to handle this? (I run on .Net 4.5) I do not consider WCF because it seems way too thick and complex for what I try to handle. I also do not want to delve into web programming, so Rest/Soap type frameworks are not under consideration. I would be delighted if anyone could recommend a tcp/websocket based framework or similar that is light weight enough to potentially send messages a lot more frequently than just every second.
Thanks a lot in advance.
Any reason why you are not considering HTTP? It is just over TCP but you don't need to worry about firewalls and stuff, especially given the fact that you want to do this over internet. Self-hosted ASP.NET Web API can be a good candidate. Fire and forget and request/response can be accomplished fairly straight forward and for streaming it has PushStreamContent. ASP.NET Web API is light weight compared to WCF and is open source. Just a suggestion, that's all.
I ended up using ZeroMQ for full-duplex communication between WPF client and Server. It is lightweight, very fast and pretty reliable for my needs.
I'm very interested in how financial data is streamed from server to client. I often here the term 'push-pull' used. I wondered if someone could give me an example (preferably in Java, C# or perhaps Javascript) how this is actually achieved? Whenever I have written amateur hobby projects at home I often end up querying a URL (containing the price) and continuously calling this within a while(true) loop, with a thread.sleep(x), even if the price doesnt change.
Thanks in advance
Don't know what you mean with 'streaming financial data', but the concept of push/pull is not limited to the financial sector :)
Generally speaking, pull strategy means that the client is actively getting data through a pre-defined communication channel (in your case a socket to an existing and known URL) and polling this channel for new information.
In contrast to that you have the push strategy where you are notified of any changes and you supply the communication channel and register it with the connection's partner. E.g. you have a webservice and your connection partner will post information to that webservice whenever he sees fit. See http://en.wikipedia.org/wiki/Observer_pattern for this concept.
Hope this helps a bit.
If client is working over HTTP the push is always initiated by client, i.e. client requests new updates and server sends them. If client is thin client (i.e. application running in browser) the modern way is to use AJAX to retrieve data without refreshing the page. But again the initiative is at client side, but user just does not see it. It is done on scheduled basis using javascript.
The most "real time" approach is using HTTP tunneling technique: client performs HTTP GET to special URL mapped to servlet that does not close the connection. It just holds it open. When it has something to send to client it writes to stream. So, you get server-to-client push, but still initial connection was performed by client.
You were doing pull. Pulling is when the clients request the data from the server and the server acts on that request.
If the server would have send you data upon receiving new data, that would have been push.
So the difference is: push is initiated by the server and pull is initiated by the client.
Financial data is often transmitted with software like TIBCO Rendezvous. A publisher sends the message to a daemon and listeners that subscribed that subject gets the message from the daemon.
Websockets
EventSource
These are the two web-based PUSH techniques.
As for browser support:
Chrome/Safari/Firefox6 support Both of those.
Opera supports EventSource and Websockets but has the latter disabled by default.
Firefox 4 supports websockets but has it disabled by default.
IE<10 supports neither, IE10 might support one if your lucky
There are many pull techniques, including HTTP and ajax.