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
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.
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
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'm writing a simple reverse proxy which will need to handle http GETs and POSTs and WebSocket connections. Numbers of simultaneous clients will be low so I had hoped to use HttpListener. I'm struggling to see how to use that to proxy a WebSocket connection though.
I think responses have to be sent via HttpListenerResponse. For GETs and POSTs this is easy. For WebSockets I'd need to send handshake data then keep the connection open to send further messages from the server being proxyed. The only way I can see to send data using HttpListenerResponse is to call Close(), presumably preventing further use of the underlying socket.
Similar issues presumably exist with trying to use HttpListenerRequest to receive later websocket messages from the client.
Am I missing something here or is there no way to use HttpListener with websockets?
Seems there is no way with HttpListener right now. You have to wait .NET 4.5.
I'm writing UI to test an asmx web service. Server and client are .NET. Client proxy has been generated using wsdl.exe.
I would like to intercept and store a string representation of outgoing and incoming SOAP messages generated as a result of calling methods on the web proxy, so I can add a feature to the UI which will show the message just sent/received.
I dimly recall there are two pairs of extension points where code can can be added to intecept the message but I cannot remember how this was done. I think the examples I have in mind involved compressing some part of the message on the client and the reverse on the server, even though in my scenario, I want to store rather than alter the message.
Any hints and help gratefully received.
(I've partially implemented a SoapExtension. I don't understand how the ChainStream method works, and I'm not sure how to notify a listener that a soap message has been trapped (since I'm not in control of instantiating the soap extension).'
You're on the right track with SoapExtension. Did you see the documentation and example here? http://msdn.microsoft.com/en-us/library/system.web.services.protocols.soapextension.aspx
The idea with ChainStream is you get passed the network stream that the request would be written to, and you have the option of returning a different stream. So if you want to save a copy of the request, return a MemoryStream, which the web services client will write the request into, and then in the ProcessMessage call you can copy the data out of there and pass it to your UI.
Another way to capture the XML is sent through the Wireshark application. It intercepts the communication network card.
In my case, I called a service that had as part of his address to string PIOSOS. I used the Find Packet window and searched.
Then located the XML.
See the picture.
(I know ... it's not a programmatic way, but it has its value. Lol)
I would suggest 2 tricks :
subclassing the proxy and overloading your methods (a little bit boring but you can generate code like in this project : http://ftwsf.codeplex.com/)
using Async signatures and subcribe to 'Completed' events of each methods (you can do this by reflection to avoid writting to much code)
If you need more info about these tricks, just let me know.
You'd really be better off using WCF as your client technology. You could then simply use WCF message-level tracing to log the incoming and outgoing messages. This is done simply through configuration.
There's no reason you have to use an ASMX client just because you are using an ASMX service.