[fixed] Client : Connetion to server problem with multiple network interfaces (1 Viewer)

[Smeulf]

Hi Smeulf,

you are on the right way!!! With your patch, the MP2-Server is found and I can attach to it. After starting MP2-Client, it takes about 5-6 seconds until the MP2-Server is found, but I think this is right. The test was done with three interfaces (wlan, vmnet1, vmnet8) enabled. Every interface had IPv4 and IPv6 enabled. And it worked!

Great news !! I'm happy !

BTW: I never had anything allowed in Win7-Firewall because this is one of the first things I disable when installing a Win7-machine for use at home. So indeed MP2-Client.exe and MP2-server.exe are not allowed on client or server, but on both the firewall is disabled. If you want, I can enable the firewall on both and allow those two exes. But anyway, it already worked in my configuration now.

Well, if it works like this, then no need to change anything else, it was just a note to be certain

However, as you pointed out, playing an MP3 from the server was no longer possible. logs attached.

Thanks a lot for your hard work!
Michael

Yep, that's the part I can't do myself, I need Albert's help on this : I added some todo in my patch, Albert, if you can take a look on it and implement the missing code ? I'm not an enought good dev to do it myself... And in the same time, I think the code needs a little rework, and you're better on it than me!

Michael, thank you very much for your help on this issue. It's always good to have new people interested in our work, and willing for help.

Cheers.

Smeulf.

 

[MJGraf]

Just had a look into the code where you put the ToDos. Now I know what you mean with "need Albert's help"
I got stuck somewhere in RemoteResourceInformationService. TryGetResourceInformationService seems to be the last point when producing an URL, where there might also be information on the interface to bind on.
Really impressive - but it will take a lot of time for me to understand what's going on behind the scenes of an MP2-Server or Client...
For now: Thanks Smeulf (and Albert of course).

 

[Smeulf]

I got stuck somewhere in RemoteResourceInformationService.

Hehe, that's the key I was looking for

I hope I did not screwed up anything in the code, but I think this patch will fix your problem to play a file.

Albert, please, your knowledge is still needed : I may have NRE in my code, and I'm not very proud of my implementation.

If it works, a clean-up/rework is very welcome.

Cheers.

 

[MJGraf]

That's it! Works like a charm Thanks Smeulf, very good job!

Just as a last note: It works absolutely reliable now. But when starting MP2-Client, it may really take a while. I usually have four network interfaces: wlan, vmnet1, vmnet8 and a VPN-Connection (OpenVPN). Every interface has IPv4 and IPv6 enabled. So that's 8 endpoints. At the moment, it takes roughly 20 seconds after the main menu appears until the menu expands because the client has found the server. For me this is absolutely ok, but I'm not sure whether the "standard-MP-user" can/wants to wait so long So maybe there's still some room for improvement (i.e. timing optimization).

Nevertheless: Very impressive and thanks - will go on testing as time permits.
cheers,
Michael

 

[Smeulf]

That's it! Works like a charm Thanks Smeulf, very good job!

Just as a last note: It works absolutely reliable now. But when starting MP2-Client, it may really take a while. I usually have four network interfaces: wlan, vmnet1, vmnet8 and a VPN-Connection (OpenVPN). Every interface has IPv4 and IPv6 enabled. So that's 8 endpoints. At the moment, it takes roughly 20 seconds after the main menu appears until the menu expands because the client has found the server. For me this is absolutely ok, but I'm not sure whether the "standard-MP-user" can/wants to wait so long So maybe there's still some room for improvement (i.e. timing optimization).

Nevertheless: Very impressive and thanks - will go on testing as time permits.
cheers,
Michael

Nice to hear it works, thanks for your confirmation.

For your comment, I'm not sure a lot of users will have a VPN and VMWare installed on their HTPC, for both Client and Server sides, unless they are power users, and in this case, I assume they can understand that with many interfaces, it takes longer than with only one...

At the very end, it's up to Albert to take the descision to try to speed up the detection or not, but IMO, it will be very difficult regarding how UPnP works.

 

[Albert]

AW: Client : Connetion to server problem with multiple network interfaces

Thanks you both for all your work. Just some background information:

The UPnP protocol proceeds in four steps:
1) Advertisement: The UPnP device says hello and the UPnP control point listens. Here, the protocol SSDP is used which goes over UDP.
2) Description: The UPnP control point requests a description XML file which describes the capabilities of the device. This goes over HTTP (using TPC/IP).
Steps 1) and 2) are executed for each available device in the network by my basic UPnP classes.
3) Control: Remote method calls from control point to device.
4) Eventing: Events about changed variables.
Steps 3) and 4) are only executed for devices which should explicitly be contacted, for example a MediaLibrary search request.

"Device" is the endpoint which is being controlled by the "control point". In MP2, both client and server are devices. The client finds the server and the server finds the client. Those processes are independent from each other, that's why it can happen that one of them finds the other but not vice-versa. That also expains why the client finds it's own UPnP device; because all available devices are found via SSDP.

For debugging our problem here, Protocol steps 1) and 2) are important. From your explanations MJGraf, I learned that the UPnP part (1) seems to work now after Smeulf's patch which forced the UDP multicasts to be made on each network interface.
The problem seems to be in part 2), where the server's description is requested.
Please do a git pull to get my latest commit. It changes the device description from "MediaPortal-2" to "MediaPortal-2-Client" and "MediaPortal-2-Server" to make it easier to debug.

If you look in UPnPNetworkTracker #286, you see this line:

  HttpWebRequest request = CreateHttpGetRequest(new Uri(rootEntry.PreferredLink.DescriptionLocation));

Please start the server in Visual Studio. Then put a breakpoint in that line. Then start the client. It doesn't matter if it is attached or not because we are working on a the UPnP description stage, which lays under the application layer.

When the server runs into that breakpoint, check if rootEntry._productVersion is the MP2 client. If not, just let it continue and wait until the line is reached for the rootEntry of the MP2 client.

Then, check the value of rootEntry.PreferredLink.DescriptionLocation. If that location contains an unreachable IP address, my search for the "PreferredLink" is maybe wrong.

 

[Smeulf]

Re: AW: Client : Connetion to server problem with multiple network interfaces

If that location contains an unreachable IP address, my search for the "PreferredLink" is maybe wrong.

I would bet your search for PreferedLink is good. Why ? Just because I use the same prefered link in my patches to retreive the local ip address where this prefered link was detected, and send the HttpWebRequest via this same local address.

I'll do the test before the end of the week, but as far as I remember, I never saw a "bad" PreferedLink while I was degugging both client and server.

It seems to be a common issue with HTTPRequest, take a look : c# - HttpWebRequest times out with multiple network adaptors enabled - Stack Overflow

Cheers,

Smeulf.

 

[MJGraf]

Hi everybody,

I executed the steps as described by Albert. But I have to explain my setup a little bit beforehand:

I Have two physical machines: A laptop and my htpc. All the tests above were made on these physical machines with the laptop as MP2-Client and the htpc as MP2-Server to exclude any problems resulting from virtual machines. But I have no development envirentment on either of these physical machines. On the htpc there is the old version of VMWare Server 2.0 running and within that, there's a virtual machine with VS Express. Therefore I had for this test to run the MP2-Server on that virtual machine to be able to set breakpoints.

MP2-Client on laptop with 4 network interfaces: WLan, VMNet1, VMNet8, OpenVPN-Tap; IPv4 and IPv6 both enabled on all interfaces
MP2-Server on virtual machine with 1 network interface; only IPv4 enabled
Result: When rootEntry._productVersion in the server is the MP2-Client, rootEntry.PreferredLink.DescriptionLocation contains the correct IPv4 address
However, I have to mention that when the server is running on the virtual machine, I CAN connect to it with MP2-Client although the client has 4 network interfaces enabled. When I do the same with my physical htpc as MP2-Server, I CANNOT connect - and unfortunately I cannot set breakpoints either because I don't want to install VS2010 on my htpc...

Maybe you, smeulf, can do the test with VS on a server that doesn't work...

Thanks again,
Michael

------------------------------------------------------------

ok, one more observation which may also be a bug, but I don't think it has something to do with the above:

MP2-Server in my virtual machine (vm) as described above. vm has only one virtual network interface. Usually there's only IPv4 enabled. I can enable IPv6 as well, but the old VMWare Server 2.0 doesn't seem to bridge IPv6-Packets.

As a result, I have MP2-Server in my vm with one network interface, both IPv4 and IPv6 enabled.
MP2-Client on my laptop with IPv4 and IPv6 enabled on all interfaces.
Although on both network interfaces, through which client and server communicate with each, other IPv6 is enabled (WLAN on laptop and virtual nic in VM), they cannot communicate via IPv6 but only via IPv4.

When I do Albert's test above, rootEntry.PreferredLink.DescriptionLocation contains the IPv6-Endpoint. Through this endpoint, there can't be a communication between client and server because I can't ping via IPv6 in one or the other direction. Ping is only possible via IPv4.

I hope this was understandable...
Michael

-------------------------------------------------------

Last test for now:

Since I don't have an IDE on my physical htpc, I included an additional log entry for the server-log. When starting MP2-client on the laptop and MP2-Server on the htpc, I get the following server-log:

[2011-10-15 14:45:29,352] [1195 ] [14 ] [DEBUG] - UPnPNetworkTracker: InitializeRootDescriptor called with rootEntry.Product_Version: 'MediaPortal-2-Server/1.0' and rootEntry.PreferredLink.DescriptionLocation: 'http://[fe80::801b:52ca:2012:a04d]:60299/upnphost/description/uuid:46d5e8b7-345a-4ce0-88dc-af7a1f8283f9'
[2011-10-15 14:45:29,352] [1195 ] [12 ] [DEBUG] - UPnPNetworkTracker: InitializeRootDescriptor called with rootEntry.Product_Version: 'MediaPortal-2-Server/1.0' and rootEntry.PreferredLink.DescriptionLocation: 'http://[fe80::8182:603b:c84d:e985]:60299/upnphost/description/uuid:46d5e8b7-345a-4ce0-88dc-af7a1f8283f9'
[2011-10-15 14:45:41,826] [13670 ] [15 ] [DEBUG] - UPnPNetworkTracker: InitializeRootDescriptor called with rootEntry.Product_Version: 'MediaPortal-2-Client/1.0' and rootEntry.PreferredLink.DescriptionLocation: 'http://[fe80::949c:2771:a3e3:1a08]:50258/upnphost/description/uuid:bcec7594-a30e-4dc6-bc69-9124b1afa6d0'
[2011-10-15 14:45:41,827] [13671 ] [11 ] [DEBUG] - UPnPNetworkTracker: InitializeRootDescriptor called with rootEntry.Product_Version: 'MediaPortal-2-Client/1.0' and rootEntry.PreferredLink.DescriptionLocation: 'http://192.168.2.22:50257/upnphost/description/uuid:bcec7594-a30e-4dc6-bc69-9124b1afa6d0'

Both IP addresses for MediaPortal-2-Client are correct. So Smeulf's idea that this can't be the reason seems to be correct.

If you need anything else tested, Albert, please let me know!
Michael

 

[Albert]

AW: Client : Connetion to server problem with multiple network interfaces

There's a new branch: UPnP_HttpLocalBindAddressFix, which provides similar fixes as the fixes from Smeulf. Smeulf and MJGraf, can you both please test that code? Thx!

And about the other problem MJGraf, you said that the PreferredLink.DescriptionLocation is a HTTP address with the IPv6 address; then the PreferredLink.Endpoint.EndpointIPAddress should also be IPv6.
The PreferredLink is always one of the links in the AllLinks property which contain links that have already received advertisement packets. So IF PreferredLink is a IPv6 link, your UPnP control point DID receive packets over it.

 

[MJGraf]

Hi Albert,

connecting works absolutely reliable now. But it still takes more than 20 seconds until the client finds the server. I read somewhere that the standard maxconnections for a servicepoint is 2. If there are 8 endpoints and the servicepoint only opens two connections at the same time together with a respective timeout this could explain the delay. But this is just a guess, if it doesn't make sense, just forget about it

After connecting, playing music works, but playing a movie raises an exception (see logs attached).

Anyway, this is the right way: Thanks a lot !
Michael