[Mono-devel-list] differences between Remoting.Channels.Tcp.TcpChannel on Mono and MS
lluis at ximian.com
Wed Jun 23 06:52:52 EDT 2004
On dt, 2004-06-22 at 22:53, Patrick McMorris wrote:
> I am using System.Runtime.Remoting.Channels.Tcp.TcpChannel in my
> application and I have noticed a couple of differences between the
> Microsoft implementation and the Mono implementation. They are...
> 1. When you create a new instance of the TcpChannel object with a
> non-zero port, the Microsoft implementation will automatically start
> listening on that port. However the Mono implementation requires
> StartListening to be called.
> 2. On Mono the top of the TcpServerChannel.StartListening function looks
> like this;
> public void StartListening (object data)
> listener = new TcpListener (bindAddress, port);
> This means that a new listener (object member) will be created each
> time, with the result that a second call to the function will cause a
> change in state, whereas in the Microsoft implementation calling
> StartListening multiple times has no additional effect.
> Now I note that the MSDN docs don't make any comment on whether the
> constructor for TcpChannel will call StartListening or not.
> Question: What is the aim of Mono's implementation of Remoting;
> 1. To implement the interface defined by the MSDN docs?
> 2. To implement the as similar functionality as possible?
The aim is both 1 and 2. We implement the behavior documented in MSDN,
but we also try to implement the undocumented behavior, if this fixes
compatibility issues with MS.NET.
However, notice that undocumented behavior can change in new versions of
the .NET framework. So if your app fails in Mono because of one of those
differences, it is probably something that you need to fix in your
I think that it makes sense to fix the second difference you found
(calling StartListening should not change the state), but do you have a
reasonable test case that fails because of the first difference?
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list