I'd like to write a program where you can have 2 clients that talk to each other in realtime. I've been looking into WCF services and Duplex messaging, data contracts etc but now I'm confused.
Basically I see it as:
[Client] --- msg --> [Server] --- msg --> [Client] and vica versa.
The server will just act as the messenger.
Could you please point me in the right direction? I'd like to use WPF for the client apps.
Check out the WCF peer-to-peer programming paradigm. It will be extended in WCF 4 (with .NET 4 - due out April 12, 2010) by allowing dynamic discovery (and article here) of other clients on your network.
This should help get you going: WCF / WPF Chat Application
Perhaps Windows Azure Service Bus (which uses WCF) might be worth a look?
Service bus can effectively be used as a message bus, which is one way to implement what you are describing.
I can think of two scenarios
The clients are the only ones that start a request, to send they push messages and to receive they request periodically for new messages. The main advantage of this architecture is that it is more firewall-proof.
The clients are also servers that receive messages relayed by the central server. The main advantage is that the clients receive updates faster and they save bandwidth.
I wrote program like your sample!!!
but it has one big different: My program have a chat server and a client. clients can chat to others.(with chat server service)
This program use two wcf service for make a connection between client and server.(client call server and send message for it,server get message from client and send for all client have connected to server)I think u used one service and must be use two service(like me) or use Duplex Service.
The sucha barber`s example is too cool(WCF/WPF Chat Application in answer eric). He used duplex services but real problem of this example is "sucah used WPF too and it s expert example for beginners (like me and u)".
If u want i can share my program!!!
seethis
Related
I'm attempting to build a live support chat application in C# using a WCF microservice and after endless searches I still can't find the answer, hopefully someone here can point me in the right direction.
My problem is that rather than a typical chat room a where users broadcast messages to all connected clients, I need the application to be more like a Live Support app found on websites such as Amazon or eBay.
Ideally multiple customer support agents will have a pre installed WinForms chat application on their machines, when a customer opens a chat window (aspx page) it will connect to a server/service and the server/service will then call all connected customer support agents until one answers. At this point the customer and agent will be connected in a private chat window.
Could somebody please give me some insight or ideas on how to do this?
Thanks,
Owen
You can use ASP.NET SignalR which is a library for ASP.NET developers that makes developing real-time web functionality easy. SignalR allows bi-directional communication between server and client. Servers can now push content to connected clients instantly as it becomes available.
Here you can find more details and many tutorials about SignalR.
The first resoult in google
A WCF-WPF Chat Application
Video tutorial
WCF Chat Application
ASP.NET Chatting using WCF Services and JSon
A simple peer to peer chat application using WCF netPeerTcpBinding
usefull lectures
HTML 5 Web Sockets
Always first ask google, above you have few ready to use projects that you can copy to your solution
EDIT:
Also as tip I can recommend bi-directional message queues at application level, then make index for messages with session and users identifier. Next step would be WCF with pop and push logic based on wait objects. At low cost you will need to lock queue. WCF will do heavy job. Also problems can occure inside app with proxy management and message sending so dedicated proxy for chat would be great and safest idea. And read about Duplex Services that can be usefull here DUPLEX SERVICE
These are my findings, not checked though:
Live Support Chat using SignalR
Parle
A tutorial from ASP.NET team:
Real-time chat with SignalR 2
The first one looks very early development stage, Parle is somewhat more promising.
Anyway, since I continue my research on the topic maybe I'd need to augment my answer. Until then the links could be a good starting point.
So I got as an assignment to make a small chat function where multiple clients should be able to connect to a server and communicate with it, the server should then be able to choose whom it wants to communicate back with. (From a dropdown list or something).
What I've been able to do so far, with help from some tutorials, is that clients can connect to the server and communicate with it but nothing more. The server can't communicate back.
I'm very new to this and have limited knowledge in both C# and TCP/IP.
https://gist.github.com/4565988 <-Contains both code for client and server.
So I what I need help with is a way for the server to reply to different clients and for the client to recieve a message from the server.
Any help is appreciated!
Best Regards, Fredrik
With regards to a starting point, I would have a look at WCF Duplex Services. Duplex allow you to subscribe to the service and send updates out using two-way communication.
Essentially you can create the server as a WCF service with a couple of methods: getclients and sendMessage. From there, a client can then subscribe to the service and (while connected) get a list of other subscribers (which you provide to the UI) and then send a message back to the service (which will then use duplexing to send it to whomever it needs to).
As long as you're not married to using sockets, this would be a lot easier than creating a protocol and managing a list of connections. There are also examples of using WCF as a chat medium available on code project.
For TCP knowledge I reconn Barbara Heckler's vid where she shows a brief implementation of such kind of server. Unfortunately in Java, but nevertheless very useful.
I reconn minute 0 - 15 for the basics (UDP) and 15 - 40 for the TCP connection and why mutlithreading is need for TCP but not for UDP.
http://www.youtube.com/watch?v=5QzNHEcLp10
It's pretty simple, really. That TCP stream you successfully extract and use to read what the client(s) sent can also be written to in order to send back something, so all you have to do is move the connection and stream objects out to shared collections of some sort so that your server-side sending logic can get at it when it wants to send something. Similarly, in the client you would issue a read on the TCP stream to read what the server sent.
This might look a question where you can read the answer on MSDN, but I still want to ask about the scenario, as I want to solve the business problem.
I have a service hosted on a server, and a client makes service calls. It currently uses netTCP binding. Everything works fine when the service is available, when the server is up and running. Now, I need to handle the server down scenario. I use the local cache file on the client to serve the client requests in case of server down scenario. Now I want to cache all the requests made while server down and want to make service calls once server is up and running.
I am thinking about using the netMsmqBinding, because all I've read suggests that it works well in the disconnected scenario.
Q.1 Can I use the netMsmq to handle this scenario?
Q.2 If not then what could be another approach with which I can follow to solve this problem?
Q.3 Can I use WS-Discovery in case of server down to find that the client calls won't be able to contact the service?
EDIT : The scenario is Client-Server. But i do need to give response on every call to the client. The client is also developed and maintained by me only so i am in a good position to implement the best suitable solution.
Please guide me as I'm not too good with WCF.
Yes, you can use netMsmqBinding for this purpose. We are doing that for services running over a satellite link that can be down often.
One important limitation you need to take into account is that all calls must be one way, being a queue-based transport. If you need to get the results of a request, you'll have to provide a separate response mechanism (it can be a similar queue in the opposite direction)
Ad question 1: using MSMQ is excellent for a scenario where the service may not always be up and running. Note that the server that hosts the message queue must be up and reachable to receive the messages. However, you haven't told us anything else about your scenario, particularly why you currently have NetTCP. The reason that's important, is because there are some things you can not do with MSMQ, for example duplex communication won't work out of the box.
Ad question 2: an alternative may be to implement logic in the client (it's unclear from the question if you're the owner of the client software) to have a local queue and retry messages later if a service is (temporarily) offline. I guess you may even have a proxy MSMQ service on the client, relaying the messages to the main service once it's up.
Ad question 3: yes, you can use Discovery for this. The service will have to announce to the clients when it goes online or offline. The simplest example is using the UdpAnnouncementEndpoint. In the clients you can use the AnnouncementService class to listen to the service coming online or offline, and keep a local list of available services. Alternatively (for example when UDP broadcasts aren't feasible) you can create a discovery proxy service at a well known location that listens to announcements, which the clients can access for instant-knowledge on whether the service they need is online
I have a server I've written in C#. I need to interface with it so I can reconfigure things, purge caches, disconnect users, view a run console, etc. I can't shut the server down to do any of these things.
The two available options, interface with the server via a Tcp connection or use the Windows conventions (some WCF?).
Which is one more reliable or a "best practice":
Tcp connection and issue requests (only let admin/maintenance requests come from localhost of course) OR
use WCF to somehow access admin/maintenance methods inside the assembly?
Thanks in advance for the nearly always useful feedback.
EDIT: Can anyone offer any alternatives to WCF? The server itself is literally 65kb. It's tiny. And all I'm trying to do now is issue a few admin/maintenance commands to the server. I'm not trying to be the server, it's already done. I just want to interact with from a local host userland application.
EDIT 2: Problem solve: I'm just using a very very small Tcp client to issue requests to my already built out protocol. It's only a couple hundred lines and no bulky overkillish WCF had to be used. WCF just seems like...too too much. That said I need to learn it anyway (and am right now), thanks for the feedback!
I would definitely recommend using WCF. You define your endpoints and the contract, then using binding you configure how the communication is done (TCP, XML SOAP, Named pipes, message queues...).
This technology is pretty convenient: if you want to move for instance from TCP to HTTP SOAP, then you just update your configuration files and it's done; no code to update. Also it's totally interoperable as you can configure WCF to use HTTP (SOAP messages) and consume your services from any language/platform. You'll also find plenty of tutorials and examples on the web.
Here's a nice article about how to host WCF (TCP communication in the example, but you can use something else by modifying the configuration) within a Windows service
You can host a web service inside windows service. It would be TCP of course but without socket level programming on the client.
You can have then a restful interface on top of it. WCF always seemed too heavy to my liking
suppose if i want to develop a windows chat application then a chat server need be developed and client too. after developing chat server apps we can run that apps in a machine and chat client will be running another pc. if those pc is not in same network suppose chat server run in a USA machine and one chat client run in Germany machine and another run in UK machine. in this situation how communication will happen using internet. all the nachine have access internet so how one chat client will login to chat server and how two chat client will communicate with each other. i just want to how data will transfer from one client to another client via chat server. please give me concept or it would be better if anyone give me a reference of a any good .net based chat application where chat server and chat client will be there.........thanks.
Generally? I don't see how this is related to C#, but client-server architecture looks like this:
Client <-----> Server
For something like you're describing where two or more clients communicate with each other, you're just talking about adding multiple clients:
Client A <----
|
----> Server
|
Client B <----
If Client A wants to send a message to Client B, then Client A sends the message to the server with some sort of information indicating that it's intended for Client B. The server then examines the message, determines that it's intended for Client B, then relays that message over its connection to Client B.
This is the fundamental definition of client-server architecture. There are more advanced architectures that mix client-server with peer-to-peer, such as Skype. In a hybrid system, the connection from the client to the server typically only carries control messages (authentication, etc.) and requests for information on how to contact another client directly. The advantage to an approach like this is that it doesn't require all of the communication between A and B to flow through the server; A and B both connect to the server, but they then ask the server how to connect to each other directly, then use that direct connection for the bandwidth-intensive communication.
That's all an aside, really, though. You should read up on client-server architecture independent of any particular language or environment before you start down the road of developing an application.
WCF Web Service with the client polling the service (simple-basic scenario - easy to implement, not very efficient)
WCF Duplex Web Service with the server updating clients when needed (a bit more complicated)
TCP Socket-based solution, hardest to implement but permits much better control. There is a very good example in Matthew McDonald's book "Pro Silverlight 3"