i'm going to build a instant messager
and now i have to decide how i implement the networking.
So far i only worked with Sockets (TCP or UDP). Now i heared about RMI (in Java) and want this in my C#-Chatapplication too.
There is .NET Remoting and WCF. I think building the instant messager with Sockets is not a good idea, right? But that should i use? .NET Remoting or WCF?
.NET Remoting seems to be the older technologie and is similar to Java RMI. I read that .NET Remoting is faster than WCT (article from 2007).
Which technologie should i use for my instant messager? I want to send formatted text from the richtextbox and inline images.
Furthermore i want to exchange files from chat-client to chat-client.
For .NET Remoting i found a tutorial which uses
ChannelServices.RegisterChannel(myChan);
But this is marked as obsolete. Is .NET Remoting a obsolete technologie?
Is it possible to send images and files with WCF or .NET Remoting or are Sockets the better choice?
I read that WCF is a collection of networking technologies (Web Services, Remoting, ...) but if i search for WCF and remote method invocation i only get examples for Web Services...
BTW: Later, i want to implement a Web-Client for my instant messager with ASP.NET. Are there some limitations respective to Networking (WCF/Remoting)?
Thank you :)
.NET Remoting is maintained for backward compatibility only as of .NET 3.0. Thus, if you are going to be using .NET 3.0 or greater, use WCF.
For your immediate use, I would suggest the NetTcpBinding. You can then select a more appropriate binding using the following chart.
.
Finally, to learn about WCF, refer to this SO question.
For your instant messager solution I would recommend WCF P2P here is an article to get you started Peer-to-Peer Programming with WCF and here it is an example of p2p on codeproject.
Related
Is there a possiblity to integrate a CF application into an nServiceBus architecture? Or are there any alternatives to nServiceBus with support for Compact Framework?
From my limited understanding of the Compact Framework, it has restrictions around reflection that could make it difficult to host the NServiceBus libraries there. You might be better off having it just call a web service that calls into NServiceBus.
We would like to develop WCF service for SL clients, which should support session management (PerSession) and callbacks. The WCF service would be hosted as a Windows service.
What would be best WCF binding choice (wsdual, pollingDuplex, any other)? Please also provide for/against points.
Regards,
There are no others. Silverlight does not support WSDualHttpBinding. You can choose PollingDuplexHttpBinding or PollingDuplexHttpBinding.
Have been working a little more in this area and it appears this is an area of constant and recent change. As of Silverlight 4, NetTcpTransport and HttpTransport are both supported using either text or binary encoding. It appears SL5 delivers further enhancements.
There is an interesting benchmark app here which allows you to profile relative performance of the two protocols. Though it was built for SL4, you can download, update the target framework to SL5 and see how it goes. It is a great way to make sure you've got everything setup properly.
Using NetTcpTransport should mean you can also use PerSession instancing on the server.
I work at a financial institution, in a team whick takes care of a "home-made" corporate component. This component was built using .NET 1.1, and the other teams use it a lot, specially along with the legacy systems (the ones which are still in .NET 1.1 too)!
Now we want to upgrade this component to .NET 4.0 so we can use some new features (in fact, we want to use Websphere MQ, and its .NET library was build over .NET 2.0). However, can't simply change the runtime of our component, because our internal clients can't afford with an upgrade to their systems.
So, we need to keep a .NET 1.1 component working as a proxy to some service built in .NET 4.0. This was where my question came from: how this interoperability can be made? My first answer was using .NET Remoting 4.0 to comunicate these two parts. Although we can use a WCF service exposed with a HTTP binding (the .NET 1.1 component uses it as it was a ASMX web service), .NET Remoting has proven its performance advantage over the previous solution, but it's a legacy framework (http://msdn.microsoft.com/en-us/library/kwdt6w2k.aspx).
What I'd like to know is if you guys have another idea to do this interop. Is there a way to call a WCF service exposed with the netTCP binding by a .NET 1.1 client?
Thanks a lot!
The real solution is to get over the problems that are forcing you to use unsupported software (.NET 1.1). Then you won't have to do horrible things like the following:
Create a .NET 4.0 class library.
Add a Service Reference to your WCF service.
Create classes and interfaces which can be used to call the WCF service.
Expose them as COM classes and interfaces
Have your .NET 1.1 code consume the COM object and make calls through it
Would be, "compare the amount of effort you just spent on trying to make obsolete unsupported code work vs. the amount of new, useful work you just did".
Note also that this technique quite rightly places .NET 1.1 in the same category as Classic ASP in terms of its ability to use modern software like WCF.
Finally, note that I haven't found a way to make the WCF client in this situation to use a config file. It was necessary to configure it in code.
Is there a reason why you can't port the component and have two versions (a 1.1 version and a 4.0) version? That would let the legacy apps continue to use the component, but your 4.0 stuff could use a newer version without all the complexity required in your proposed solution.
Different versions of .net assemblies can play nice with each other, you aren't forced to only have one version of the component.
I need a way to exchange data between a process and a windows service.
The process (Windows Form Application, Console Application, in the future also a Web Solution) needs to instruct and interact with the windows service.
I want to know which way is the best to accompplish this.
I'll write the solution in C#, .NET Framework version does not matter.
In the past I've used Remoting (Activator), WCF Interface with Contracts, Inter Process Exchange IPC and some named pipe implementation. What is your experience? Other ways?
I would choose WCF. It is most modern and probably best supported approach at the moment. It "replaced" older technologies in most scenarios. Nice feature of the WCF is that if you need to move your service to other protocol you can do that simply in configuration.
If you expect that windows service will always run on the same machine as other application you can use WCF with netNamedBinding. If you decide to move your service to other machine you will have to change configuration (probably to netTcpBinding) because Named pipes in WCF are limited only to IPC.
My previous experiences have always been over an IPCChannel, mainly because the only code I've had to be involved in that does any form of inter-process communication. It's never caused me any problems and the code is working away quite merrily as I type.
The only real answer to this question is, whichever you're most comfortable with.
I would like to host a service on a WinCE device. The WinCE device is the host which can be accessed(control and data acquisition) by multiple clients (PC or WinCE) over serial port, TCP, USB etc. I was considering using Protocol Buffers for serialization on the wire. It would be ideal to use WCF or remoting but as far as I see they are not implement on the Compact Framework. Anyone have any ideas how this can be achieved.
CF 3.5 has some WCF, but at current only the full-fat framework has WCF with the hooks to support swapping out the serializer on the fly. I know of some users who are using CF but passing a Stream over the wire (as far as WCF is concerned) and handling the protobuf-net (de)serialization outside of WCF (a byte[] may work similarly, but they chose Stream - I can't recall why- perhaps base-64 issues?). Would that help?
It's a blatant plug, I admit, but you might consider hosting a REST web service from the device.