[Mono-bugs] [Bug 444431] New: SOAP remoting references inaccessible URI

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=444431


           Summary: SOAP remoting references inaccessible URI
           Product: Mono: Class Libraries
           Version: 2.0
          Platform: x86-64
        OS/Version: Ubuntu
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: System
        AssignedTo: mono-bugs at lists.ximian.com
        ReportedBy: jay at jcornwall.me.uk
         QAContact: mono-bugs at lists.ximian.com
          Found By: Community User


Created an attachment (id=251750)
 --> (https://bugzilla.novell.com/attachment.cgi?id=251750)
Client / Server remoting test case; use a packet tracer to observe SOAP
traffic.

Attached to this bug report is a test case that provides a client and server
for a trivial System.Runtime.Remoting call. In itself it does not trip an
exception, but a packet trace (e.g. with tcpdump or wireshark) will reveal the
problem described below. To reproduce the client and server must be run from
distinct IPs.

The SOAP protocol implemented by System.Runtime.Remoting in Mono causes
exceptions in complex RMI applications. Such an exception in a .NET client
(which is more verbose than the Mono client's exception) is shown here:

System.Net.WebException: Unable to connect to the remote server --->
System.Net.Sockets.SocketException: No connection could be made because the
target machine
actively refused it 127.0.0.1:52938
   at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot,
SocketAddress socketAddress)
   at System.Net.Sockets.Socket.InternalConnect(EndPoint remoteEP)
   at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure,
Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState
state, IAsyncResult asyncResult, Int32 timeout, Exception& exception)
   --- End of inner exception stack trace ---

Server stack trace:
   at System.Net.HttpWebRequest.GetRequestStream()
   at
System.Runtime.Remoting.Channels.Http.HttpClientTransportSink.ProcessAndSend(IMessage
msg, ITransportHeaders headers, Stream inputStream)
   at
System.Runtime.Remoting.Channels.Http.HttpClientTransportSink.ProcessMessage(IMessage
msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders&
responseHeaders, Stream& responseStream)
   at
System.Runtime.Remoting.Channels.SoapClientFormatterSink.SyncProcessMessage(IMessage
msg)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 type)
   at EthTV.Common.IRemoteInterface.GetChannels()
   at EthTV.Client.ServerControl.HandleOpenConnection(String host, Int32 port)
in C:\Users\jay\Desktop\Dev\ethtv\client\ServerControl.cs:line 124

I believe that it is caused by the Mono remoting server providing an
inaccessible URI in its responses. Here is part of a packet trace from a Mono
server and Mono client:

<a2:ChannelDataStore id="ref-12"
xmlns:a2="http://schemas.microsoft.com/clr/ns/System.Runtime.Remoting.Channels">
  <_channelURIs href="#ref-14" />
  <_extraData xsi:null="1" />
</a2:ChannelDataStore>
<SOAP-ENC:Array id="ref-14" SOAP-ENC:arrayType="SOAP-ENC:string[1]">
  <item id="ref-15">http://127.0.0.1:8000</item>
</SOAP-ENC:Array>

And the equivalent trace with a .NET server and Mono client:

<a3:ChannelDataStore id="ref-12"
xmlns:a3="http://schemas.microsoft.com/clr/ns/System.Runtime.Remoting.Channels">
  <_channelURIs href="#ref-14"/>
  <_extraData xsi:null="1"/>
</a3:ChannelDataStore>
<SOAP-ENC:Array id="ref-14" SOAP-ENC:arrayType="xsd:string[1]">
  <item id="ref-15">http://192.168.1.3:8000</item>
</SOAP-ENC:Array>

Notice how the .NET server provides its publicly accessible URI while Mono
provides a localhost (127.0.0.1) address. I am not entirely sure when this URI
is used - as this test case does not use it - but it causes exceptions in more
advanced remoting applications.


-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.