I need to re-write an existing client-server application.
The existing application communicate using socket, I have to convert it into WCF.
At server side I need to
Monitor connected clients
Validate client request
Broadcast live data (comming from diff source).
Listen to client and respond to it
At client end I need to
Receive server broadcast and display it on UI.
Display UI and take input from user
Submit user data to server and display response
I have chosen tcp protocol on self hosting environment.
I need some immediate level references (link, tutorial, book)...
Have a look at this MSDN article, covers pretty much everything you need to know to build a duplex service in WCF:
http://msdn.microsoft.com/en-us/magazine/cc163537.aspx
You can try this : WCF on MSDN
I don't know if you can get it, but Microsoft book on WCF (course 6461A) is not bad.
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.
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.
Tooday I use ServiceHost for self hosting WCF cervices.
I want to host near to my WCF services my own TCP programm for direct sockets operations (like lien to some sort of broadcasting TCP stream)
I need control over URL namespaces (so I would be able to let my clients to send TCP streams directly into my service using some nice URLs like example.com:port/myserver/stream?id=1 or example.com:port/myserver/stream?id=anything and so that I will not be bothered with Idea of 1 client for 1 socket at one time moment, I realy want to keep my WCF services on the same port as my own server or what it is so to be able to call www.example.com:port/myWCF/stream?id=222... and I want it to work on Any port - not only 80)
Can any body please help me with this?
I am using just WCF now. And I do not enjoy how it works. That is one of many resons why I want to start migration to clear TCP=)
I can not use net-tcp binding or any sort of other cool WS-* binding (tooday I use the simpliest one so that my clients like Flash, AJAX, etc connect to me with ease).
I needed Fast and easy in implemrnting connection protocol like one I created fore use with Sockets for real time hi ammount of data transfering.
So.. Any Ideas? Please - I need help.
Well if you're going to drop down to pure sockets, you could as well make your service act as proxy. Make WCF Services listen on some other port, and your app on the desired port. When you receive request in your app, manually parse header and check weather it is intended for your service or WCF Service. If it's intended for WCF service, open a TCP connection to WCF service and pass the received data to it, and then simply pass back WCF's answer to the client..
On the other hand you could speed up WCF quite a lot by writing your own custom binding. Lots of time WCF looses on serialization that is done using reflection (which is slow), going around this would improve your speed considerably.
If your problem with WCF is performance then you should try the binary net TCP binding to eliminate XML serialization to improve performance.
Some high traffic applications, like realtime games, use UDP for the majority of communication since it cuts through the protocol. With TCP you get ordering and reliability built in, but this comes at the cost of performance because it will implicitly delay packets to wait for out of order packets so that it can hand them to the application in the correct order, or wait for lost packets to be resent. Instead you can use UDP and implement your own scheme for verification of data that is less stringent than TCP.
There are UDP options available for WCF, or you could implement your own. WCF is nothing more than a message pump, and you can replace different steps with whatever you want.
Not sure if this will help you or not, but try turning on your Net TCP Sharing Service.