I want to implement a simple cardgame in silverlight that can be played together via a server.
My question is, what concept for communication between client and server I should use.
Is it possible to use WCF to
implement the server ? I guess no because its more like a dataprovider right ?
or do I need to use .NET Remoting ? Haven't read much about it yet, but
I'm not quite sure if it is maybe out
of date ?
Maybe there are newer approaches that I don't know yet ?
Maybe someone has a good tutorial link for the beginning that is not a bad coded sample from year 2002
WCF and .NET Remoting define communication protocols, that is, they define the plumbing between client and server.
When writing a client/server application, you should use WCF as .NET Remoting is deprecated.
See this code project article and code for a simple client/server implementation using WCF. The code is for uni-directional communication, where the server responds to the client.
Here is another article, with a more complicated sample (chat client), using bi-directional communications between client(s) and server. It also uses WPF as the UI layer, so you may need to read around that if using winforms.
WCF (Windows Communication Foundation) is the .NET technology for communication. It includes simple client / server scenarios, as well as publish / subscribe and peer to peer.
Ignore .NET Remoting. It has been replaced by WCF.
I have no idea why you thought that WCF was a data provider, but you're mistaken. See the WCF Developers Center for more on WCF.
Related
I need to make full duplex connection between server and client. Currently I have .net 4.5 wpf client. My initial thoughts was about wcf service with netTcpBinding. But it seems to be working only on windows 8. And client app has to be launched on windows 8.
I but I'd like to support windows 7 at least. I saw alternative in SignalR, but it will use server-sent events and I'm not sure in it.
Is it better to make web client with js connection to service? According to http://caniuse.com/websockets chrome and firefox supports it for a long time. If so can I host wcf service with websockets and connect to him from js? I'm wondering why browser supports it and in same time wpf doesn't...
Also performance for connection is not last thing, it should real fast.
WebSockets are a technology for allowing bidirectional comms over a single TCP connection. It is intended to be used between browsers and webservers, but that doesn't mean you can't use it in other platforms.
There is a C# WebSocket client out there on GitHub (also on NuGet) that you could use to experiment with.
https://github.com/sta/websocket-sharp
Looking at your question, I do not believe that netTcpBinding is the best choice for this. If I where you I'd use this binding: binding http://msdn.microsoft.com/en-us/library/system.servicemodel.wsdualhttpbinding(v=vs.110).aspx
That binding is SOAP so you're likely to get better compatibility and it is designed specifically for duplex connections.
As for SignalR and js connection to service I would say at this point you seem to have a working solution and changing the binding is probably a short solution; however, only you can really know for sure.
I don't think you need this; however, just in case here is an example of using duplex over wcf. (I used TcpNamedPipe in this example instead of WSDualHttpBinding; however, you only need to make minor changes to get the desired result)
https://github.com/Aelphaeis/MyWcfDuplexPipeExample
I am interested in deploying a server to GoDaddy as a C# web application, then have desktop clients developed in C# and Java be able to subscribe/publish to the server using WebSockets (RFC 6455).
WebSocket supported libraries I am looking at are XSockets.Net and SignalR.
I am not able to find anything on using XSockets.Net (not to be confused with XSocket.org) in Java. I understand that XSockets targets MS .Net framework and Mono environments. However, looking at SignalR, there is also SignalA which is a Java based SignalR client for Android.
Thinking-out-loud... I understand there are many WebSocket libraries for Java, which suggests the idea that if I am able to publish a message (using WebSocket) from a Java application to a server, then I should be able to read it and processes it in C#, since WebSocket protocol is a standard.
Thus far, I believe a SignalR solution will satisfy my requirement to allow C# & Java applications to talk on the Web, but due to transport requirments of SignalR, my communication will not utilize WebSockets. Reading through SignalR requirements, to get WebSockets transport activated I must use Windows8+ with .Net Framework for 4.5+. GoDaddy does not use Windows8 for windows hosting, and even if it did, then all my clients must also use Windows8, which is not a guarentee.
So the question is: How can I get C# & Java desktop clients to talk on the web via WebSockets, othan than using SignalR and XSockets.Net?
Any help is very much appreciated!
EDIT: I will now look into deploying a C# XSockets.NET Server and have a C# XSockets.NET client and a Java JWebSocket client since both JWebSockets and XSockets support the WebSocket RFC6455 protocol. I will post my findings here and close this question if that was a successful effort.
You can implement a RFC6455 client in any language and use XSockets. However do note that XSockets uses a publish/subscribe pattern that you will have to implement as well to take benefit of the platform.
The upside is that you actually wont have to implement RFC6455 since you can implement a custom (non websocket protocol) and use that when communicating from desktop (or anything else). Since everything in XSockets is a plugin you can add custom protocols and still communicate with client talking RFC6455 since XSockets will offer cross-protocol communication.
So the thing you have to implement is actually only the publish/subscribe functionality in the java client.
There are probably not any Java clients out there that implements the IXSocketClient interface today, and we focused on Mono instead of Java when covering multi-platform support.
We will help you out in any way we can if you decide to write your own java implementation.
Note: as of the next version (not far away) it will be very easy to implement your custom protocol and connect from any device talking TCP/IP
In my humble opinion, you have misunderstood some things.
XSockets and SignalR are libraries which are totally oriented to a specific platform, .NET. They both wrap the functionality of WebSockets, a platform independent standard, to ease its use. This does not by anyway mean that you could use XSocket, or SignalR libraries in all platforms.
I suppose that creating a java client for XSockets or SignalR would be an overkill and would lead you to heavily depend on a 3rd party library. In your situation, I would go on with using WebSockets directly on my server side. Then I would use a library handling the WebSockets standard for each client, which could be different for each client development platform. Therefore, you would depend on one universal standard and you would minimize dependencies on 3rd party libraries.
Hope I helped!
I'm trying to figure out which client/server technology (i.e. which part of the .NET Framework) to use for our new application. We will be writing the app in C# using .NET 3.5 SP1.
It is going to consist of a central Service that will be running as a "server", and several client applications spread out on several machines. The client application is a trayapp application that is going to receive notifications from the server, and will also send some information back to the server. The communication will therefore be two-way, and it needs to be fast. The server will need to know which client to send the notifications to.
I've been thinking that I could use Sockets. I've also come across the TcpListener and TcpClient classes. Another alternative is to do something with WCF, but I'm not sure how to do fast two-way communication with it.
WCF with NetTcp binding.
You should write a duplex service.
Without knowing how much data you're planning to exchange, it's difficult to make a precise recommendation. I use both WCF and TCP sockets to exchange data between my UI and my Windows service. Here are the considerations I made.
I use WCF for what I refer to as aperiodic data exchange. For example, when an event occurs in my Windows service, I communicate the event to the UI using WCF. Specifically for this event-based mechanism, I would highly recommend Juval Lowy's Publish-Subscribe Framework, which is available for free here. I also use WCF to communicate configuration changes from the UI to the Windows service. WCF is a perfect solution for this kind of data exchange for me.
When the user tells my Windows service to perform some action, a lot of data is sent from the Windows service to the UI. For this, I use TCP sockets. I know WCF has a streaming capability, and I strongly considered using it. I just did not have time to get comfortable with it before I had to make a decision, so I went with what I knew.
While I wish I was using WCF across the board for symmetry, i.e., for aperiodic and streaming data, this hybrid approach has served me well.
Hope this helps.
I would avoid sockets if I were you since there is a lot to know about them. Just look at all socket questions here at SO. It can be a nightmare if you do not know how to use them properly.
WCF will take care of all lower levels for you.
I'm planning a project which will consist of a Windows Server Application programmed in .Net/C# and Clients programmed in Silverlight/C#, Windows Forms/C# and a MacClient programmed in Cocoa. My Question is, which Webservice technology will be the best for the communication between the Clients and the Server and is the easiest to program in all of those technologies? I've no experience in Webservices and since Time is running short I hope to get some opinions of developers who worked in such a kind of heterogeneous project.
On the back end, you will definitely want to run Windows Communication Foundation, using the WSHttpBinding or the BasicHttpBinding depending on your needs.
This will make it easier to have Windows Forms and Silverlight clients.
Also, because using WCF with those bindings conforms to established standards, you should be able to access the services from almost any other environment - there should be tools that you can just point it to your metadata endpoint and it will generate proxies for you.
Another option is to use WCF to create a REST service (with JSON encoding most likely). WCF does help you a little bit here, but if this is the design you want to use, then you will want to look at ASP.NET MVC on the back end as well, as it makes creating these kind of services very, very easy.
However, when using REST services, there isn't a service description through something like WSDL, so you will have to generate the proxies to call your services by hand (at least, in environments outside of .NET).
The current technology used to develop web services on .NET is WCF. For interoperability with non .NET clients you should consider using basicHttpBinding endpoint. You could even expose multiple endpoints with different bindings, for example expose interoperable endpoint for non .NET clients and some fast binding for .NET clients. Here's a nice article on MSDN covering the performance of the different bindings. Given those keywords you might checkout the tutorials.
I would like to have a client-server application written in .NET which would do following:
server is running Linux
on the server there is SQL database (mySQL) containing document URLs
What we want:
- server side would regularly crawl all URLs and create a full text index for them
- client side would be able to perform a query into this index using GUI
The client application is written in .NET using C#. Besides of searching in documents it will be able to do a lot of other things which are not described here and which are done client-side very well.
We would like to use C# for the server side as well, but we have no experience in this area. How are things like this usually done?
Clarifying question now based on some answers:
The thing which is most unclear to me is how client-server communication is usually handled. Is client and server usually using sockets, caring about details like IP addresses, ports or NAT traversal? Or are there some common frameworks and patters, which would make this transparent, and make client-server messaging or procedure calling easy? Any examples or good starting points for this? Are there some common techniques how to handle the fact a single server is required to server multiple clients at the same time?
To use c# on Linux you will need to use Mono. This is an open source implementation of the CLR specification.
Next you need to decide on how to communicate between server and client, from the lowest level of just opening a TCP/IP socket and sending bits up and down, to .Net remoting, to WCF, to exposing webservices on the server. I do not know how compleat WCF implementation is on mono, also I think you may have issue with binary remoting between mono and MS .Net .
I would suggest RPC style WebServices offer a very good solution. WebServices also have the advantage of alowing clients from other platforms to connect easily.
EDIT
In response to the clarification of the question.
I would suggest using mono/ASP.NET/WebServices on the server, if you wish to use c# on both server and client.
One assumption I have made is that you can do a client pull model, where every message is initiated by the client. Using another approach could allow the server to push events to the client. Given the client has the ability to pole the server regularly I don't consider this much of a draw back but it may be depending on the type of application you are developing.
Mono allow execution of c# (compiled to IL) on a Linux box. Mono ASP.NET allows you to use the standard ASP.NET and integrate into Apache see http://www.mono-project.com/ASP.NET and finally WebServices allow you to communicate robustly in a strongly typed manner between you client and your server.
Using this approach negates most of the issues raised in your clarification and makes them someone else's problem.
Sockets/SSL - is taken care of by standard .Net runtime on the client and Apache on the server.
IPAddress/ports/NAT traversal - Is all taken care of. DNS look up will get the servers IP. Open socket will allow the server to respond through any firewall and NAT setup.
Multiple Clients - Apache is built to handle multiple clients processing at the same time as is ASP.NET, so you should not encounter any problems there.
As many have already mentioned there are a number of thing that you have mentioned which are going to cause you pain. I'm not going to go into those, instead I will answer your original question about communication.
The current popular choice in this kind of communication is web services. These allow you to make remote calls using the HTTP protocol, and encoding the requests and responses in XML. While this method has its critics I have found it incredibly simple to get up and running, and works fine for nearly all applications.
The .NET framework has built in support for web services which can definitely be called by your client. A brief look at the mono website indicates that it has support for web services also, so writing your server in C# and running it under mono should be fine. Googling for "C# Web Service Tutorial" shows many sites which have information about how to get started, here is a random pick from those results:
http://www.codeguru.com/Csharp/Csharp/cs_webservices/tutorials/article.php/c5477
have a look at Grasshopper:
"With Grasshopper, you can use your favorite development environment from Microsoft® to deploy applications on Java-enabled platforms such as Linux"
Or see here
The ideea is to convert your app to Java and then run it on Tomcat or JBoss.
Another approach: use the Mod_AspDotNet module for Apache, as described here.
This Basic Client/Server Chat Application in C# looks like a kind of example which might be a starting point for me. Relevant .NET classes are TcpClient and TcpListener