[Mono-devel-list] differences betweenRemoting.Channels.Tcp.TcpChannel on Mono and MS

[Patrick McMorris]

I agree with you on point 2 this should be fixed and I will log a bug in
Bugzilla for the same.

For point 1, we do have a legitimate test-case... in the 'normal' case
where the channel is created and registered with remoting, both Mono and
the Microsoft implementation behave the same. However we have a case
where we legitimately *don't* register the channel because we don't want
any references to that channel in ObjRefs that our process gives out. In
this case, Mono and the Microsoft implementation behave differently, as
for Mono we must call StartListening.

However personally I think it is wrong that Micrsoft do that in the
constructor, and even worse that they don't document that behaviour. So
I am happy enough to call it now that I understand this issue.

Consider this; We have a large amount of code we have implemented
against the Microsoft CLR and BCL and we are now seeing if we can run it
on Mono, a number of small difference like this are making that a lot
harder as we track them down and modify out code to 'fit' both. So from
that point of view the difference is just a hassle. Having said that we
have found this one now so I don't mind if it changes or not, but it
could be the thing that trips other people up in future.

Personally I wouldn't change it,

Thanks
Patrick

-----Original Message-----
From: Lluis Sanchez [mailto:lluis at ximian.com] 
Sent: 23-Jun-04 06:53
To: Patrick McMorris
Cc: mono-devel-list at lists.ximian.com
Subject: Re: [Mono-devel-list] differences
betweenRemoting.Channels.Tcp.TcpChannel on Mono and MS

On dt, 2004-06-22 at 22:53, Patrick McMorris wrote:
> Hi,
> 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
application.

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?

Lluis.

> 
> Thanks
> Patrick
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list