Did Wcf replace socket?
for client server application i need that client send some messages to server and the server can do the same thing without waiting request from any client.
So can i do this or wcf can only expose many services that client need and the communication can't be interactif and bidirectionnal?
thanks
Do you want the connection to be persistant? If so then this doesn't sound like a good case for WCF. Perhaps take a look at something like ZeroMQ instead.
Wcf will never replace the sockets. The WCF just implements some concrete protocols over the TCP so if you need something else like IP or even UDP you still need to use the sockets.
If you need a stable TCP connection you still need a socket. Also this discussion could be helpful for you.
http://forums.silverlight.net/t/17502.aspx/2/10
Related
Is this possible to make a tcp IP communication to receive any content which is waiting, from C# code on demand ?
There is a tutorial at http://www.codeproject.com/Articles/312530/Calling-Webservice-Using-TCP-IP-from-any-Programmi which utilizes tcp connection to consume a web service. You may want to check it.
I am developing a winform application.I need to implement real time notifications into it.After searching a lot on the net, I have found out that it can be done using web-sockets technology.But creating sockets is also a way of creating a bidirectional connection with the server.So,can't we just create a socket connection to the server and just don't close it.So,when server has to send some notification to the client then it can do so through that socket.If Yes, then what is the need of web-sockets? And if No, then what exactly is the difference between web-sockets and sockets?
If you control the technology used on both the server and the client, I would definitely recommend using SignalR
Because:
It's dead easy to set up
Allows you to broadcast messages to virtually any number of clients
Manages keep-alive and re-connections for you
Provides an easy to use RPC style messaging pattern
Picks the best connection method for you, depending on the type of connection and client
Allows you to use javascript clients too (using a jQuery-like library)
Doing your own socket implementation for these kind of purposes is not very "2015" ;)
If you want to use sockets, the way I would go about this is to create a Listener in the client application, and for the server to send packets to this listener.
This is a good resource to help you get started
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.
The remote client is a desktop application running a windows.forms application. How do I have the server send the client a message, knowing the client's IP address?
Check out these tutorials:
Simple Threaded TCP Server
High Performance TCP/IP Server using C#.NET
Building a TCP/IP server using C#
and these books
TCP/IP Sockets in C#: Practical Guide for Programmers (The Practical Guides)
C# Network Programming
Although sockets is an option, you may want to consider using a higher level abstraction such as the one provided by WCF.
WCF's Duplex Services allows you to implement communication going both ways (client -> server) and (server -> client) with some flexibility on choosing transport and protocol.
A common way to do this is using sockets.
Basically you open up a communication channel to the remote client using TCP/IP and can send messages back and forth. Both sides must know about the other and must agree on a message format.
When using sockets, you communicate on a port. Several ports are reserved for (or at least typically used by) certain protocols. For example, HTTP uses port 80 by default. You will want to select a port not already in common use. Also be sure that any firewalls between both ends allow communication on that port.
It could largely depend on the existing protocol that is being used between the client and the server. If the server is HTTP, then the client could poll to see if there are messages. If the client is already using TCP/IP, then ideally the server can send a message to the client any time it needs to.
Also, keep in mind that opening a communication channel may essentially be one way (i.e. from the client to the server), depending on firewall configuration (such as NAT).
In general terms you do that by replying to a request of the client. If you don't have client requests, the distinction between servers and client becomes rather blurred.
What do I use for two way communication over the internet without the necessity to open ports on the client side?
Users won't agree to open ports and do port forwarding on the client side although everything is possible on the server side.
But,I need to accomplish two way communication..
How do I go about achieving this?
It doesn't matter whether its WCF or remoting or webservices...
I just need a quick and fast way to just get the concept to work out and distribute the application.
ofcourse,it's going to be through the internet.
Please help..
Thanks
Edit : Please note that i need to connect multiple clients and maintain a session for each client.
WCF supports duplex HTTP bindings.
As long as the initiating client can access the service, a callback contract can be defined to call the client. It simply keeps the HTTP connection once the client has initiated it.
It depends what you want to do. Duplex WCF can work, but through NAT and Proxies it becomes somewhat "iffy" because it depends on the client opening a WCF endpoint and maintaining the connection.
I wrote a beginners guide to WCF callbacks a while ago - it's simple enough to do, but you'll need to test it a lot, from various client setups.
Connect via TCP (raw sockets, or higher implementation) to a your central server.
Your server should have an application that listens to a specific, well known, TCP port.
Each client connects to your server, using the specific port, and "logs in".
Write an application protocol above the TCP (authentication, session management, etc.), and there you have it, since a TCP connection, once established, works for both directions.