RTD Demo will not connect to Lightstreamer Server

Printable View

January 11th, 2011, 06:12 PM
krohnjw

RTD Demo will not connect to Lightstreamer Server

Hello,

We are having some difficulty connecting the RTD server to our Lightstreamer server.

I've changed the pushServerHost and the pushServerPort in RtdServer.cs as well as added some login credentials using connInfo object (User, Password), however we cannot connect to our Lightstreamer server.

The UI loads and hangs connecting to the RTD server. Is there anything else necessary to specify to connect or some way to enable more debugging output on our Lightstreamer server to help see if the connection attempt is being made and/or what info is being passed in?
January 12th, 2011, 11:51 AM
lxnay

Hi,
we would like to know more info about your issue.
First of all, is the RTD server running locally, or is it on a remote computer?

The demo is meant to be run locally (both server and client).
If you plan to use a remote RTD server, you need to decouple the server part of the library from the client part, which is actually outside the scope of the demo itself.

Once you've moved the server part to a separate library, you need to install it on the server machine and register against DCOM (the .dll will be a COM resource).
Same thing for the client part, you need to write and register it on every client in which your RTD service should be available.
January 12th, 2011, 03:32 PM
krohnjw

Quote:

Originally Posted by lxnay

Hi,
we would like to know more info about your issue.
First of all, is the RTD server running locally, or is it on a remote computer?

The demo is meant to be run locally (both server and client).
If you plan to use a remote RTD server, you need to decouple the server part of the library from the client part, which is actually outside the scope of the demo itself.

Once you've moved the server part to a separate library, you need to install it on the server machine and register against DCOM (the .dll will be a COM resource).
Same thing for the client part, you need to write and register it on every client in which your RTD service should be available.

It is running locally - at this point we are just trying to get the RTD Demor to connect to our Lightstreamer server and receive updates from it.

From the readme it appears this should be as simple as changing the pushServerHostURL and setting the appropriate port. I've changed this and added some login credentials to the LightstreamerClient.Start method so that it should successfully connect to our Lightstreamer server, but this does not appear to be successful.

When the UI loads the connection is started but we don't appear to progress past

Code:

new ThreadStart(delegate() { lsClient.Start(pushServerUrl); }).Invoke();

in RtdServer.ServerStart(). I put an output before the call to the Start method and after and we never reach the second output. Excel eventually throws a dialog that it is waiting for another task to complete an OLE operation.
January 12th, 2011, 11:27 PM
lxnay

It looks like a network issue (firewall?).
Please have a look using wireshark and see what's going on at the NIC level.
February 1st, 2011, 03:39 PM
krohnjw

Quote:

Originally Posted by lxnay

It looks like a network issue (firewall?).
Please have a look using wireshark and see what's going on at the NIC level.

Sorry it took so long to reply - I got caught up doing other things. Firewall is disabled to rule out potential issues there. Wireshark doesn't show a single outgoing packet headed to the server. I've specified the URL as both a FQDN and IP (in case name resolution was failing for some reason) and still don't see any packets heading for the destination as expected.
February 2nd, 2011, 04:55 PM
lxnay

Just a question and a request, if possible.
Question: what do you mean with "I've changed this and added some login credentials to the LightstreamerClient.Start method so that it should successfully connect to our Lightstreamer server". What login credentials? Are you talking about HTTP AUTH? Can I have a code snippet that shows how you did that? Are you running behind a proxy? Please note anyway that all this is outside the scope of our, very simple demo.
Request: Could I have a diff between the demo code and your changes, or alternatively, could you attach your code here?

Thanks
February 2nd, 2011, 05:07 PM
krohnjw

Quote:

Originally Posted by lxnay

Just a question and a request, if possible.
Question: what do you mean with "I've changed this and added some login credentials to the LightstreamerClient.Start method so that it should successfully connect to our Lightstreamer server". What login credentials? Are you talking about HTTP AUTH? Can I have a code snippet that shows how you did that? Are you running behind a proxy? Please note anyway that all this is outside the scope of our, very simplified demo.
Request: Could I have a diff between the demo code and your changes, or alternatively, could you attach your code here?

Thanks

Changed in rtdserver.cs

Code:

private const string pushServerHost = "http://ourhostname.here"; // port, if different from 80 private const string pushServerPort = "80";

Changed in LightstraemerClient.CS:Start(string pushServerUrl)

Code:

// Added login credentials connInfo.User = "myUsername"; connInfo.Password = "myPassword";

I've added some output to RtdServer.cs:ServerStart(IRTDUpdateEvent CallbackObject) to verify the url it is using to instantiate the connection as well as when it passes - we never reach "Exited Connection".

Code:

flowForm.AppendExcelLog("Connecting to " + pushServerUrl); new ThreadStart(delegate() { lsClient.Start(pushServerUrl); }).Invoke(); flowForm.AppendExcelLog("Exited Connection");

We are not running behind any sort of proxy. All I am trying to do is get the RTD demo to connect to our lightstreamer server as it says it should be able to right in the README.

Quote:

Obviously you could test the application against your Lightstreamer server
installed somewhere, but in this case, you have to recompile the source code
after having changed "pushServerHost" and "pushServerPort" variables in
RtdServer.cs.

This is where the issue comes in to play. I don't see a single packet headed towards our server at all in wireshark, despite it seemingly being as simple as changing the host/port configuration and recompiling. The GUI launches fine and it says it's connecting to the appropriate host/port but I see no traffic in wireshark backing this up.

If you'd like to supply an email I can email the 2 changed files if you would like to see the full source. The only changes are detailed above though.
February 2nd, 2011, 06:28 PM
lxnay

Thanks,
I'll have a look at the issue in the next 24/48 hours (hopefully even before).
In the meantime, you could send us the source (please strip off sensible information from it) at support@lightstreamer.com

Regards,
February 2nd, 2011, 06:49 PM
krohnjw

Quote:

Originally Posted by lxnay

Thanks,
I'll have a look at the issue in the next 24/48 hours (hopefully even before).
In the meantime, you could send us the source (please strip off sensible information from it) at support@lightstreamer.com

Regards,

Sent as requested.
February 4th, 2011, 11:24 AM
lxnay

Thanks for your patience,
I just reviewed your changes and didn't see anything that could cause the freeze on the connection attempt (the socket in use is a blocking socket, hence the freeze if the server cannot be reached, until timeout, which is set at ~30 seconds by default).
I have two suspects by the way:
1. The server cannot be reached, might be some firewall? Can you reach the server from the browser (just connect to the same URL)
2. More probable: you are not using your re-compiled .dll. You probably installed the demo and your Visual Studio is not overriding registry settings created by the demo installation. This is easy to fix, just open the registry editor (regedit) and look for the following keys:

- HKEY_CLASSES_ROOT\CLSID\{2368E0E6-1ED6-3C39-8FAE-45B4A9FB53F3}\InprocServer32\CodeBase
- HKEY_CLASSES_ROOT\CLSID\{2368E0E6-1ED6-3C39-8FAE-45B4A9FB53F3}\InprocServer32\1.0.0.0\CodeBase

[or just search through the whole registry for RTDLibraryExcelDemo.dll]

Make sure to overwrite the .dll at the path contained in the keys above or provide a valid path to your .dll by changing those default values.
February 4th, 2011, 01:11 PM
krohnjw

1 Attachment(s)

Quote:

Originally Posted by lxnay

Thanks for your patience,
I just reviewed your changes and didn't see anything that could cause the freeze on the connection attempt (the socket in use is a blocking socket, hence the freeze if the server cannot be reached, until timeout, which is set at ~30 seconds by default).
I have two suspects by the way:
1. The server cannot be reached, might be some firewall? Can you reach the server from the browser (just connect to the same URL)

The server is definitely reachable. I can connect manually via http as well as other lightstreamer clients are using this server. We have a second server in a different data center as well that I can reach via HTTP but I see the same behavior with the RTD server as the primary (hangs in connect, no traffic going to the server in wireshark).

Quote:

Originally Posted by lxnay

2. More probable: you are not using your re-compiled .dll. You probably installed the demo and your Visual Studio is not overriding registry settings created by the demo installation. This is easy to fix, just open the registry editor (regedit) and look for the following keys:

- HKEY_CLASSES_ROOT\CLSID\{2368E0E6-1ED6-3C39-8FAE-45B4A9FB53F3}\InprocServer32\CodeBase
- HKEY_CLASSES_ROOT\CLSID\{2368E0E6-1ED6-3C39-8FAE-45B4A9FB53F3}\InprocServer32\1.0.0.0\CodeBase

[or just search through the whole registry for RTDLibraryExcelDemo.dll]

Make sure to overwrite the .dll at the path contained in the keys above or provide a valid path to your .dll by changing those default values.

I can say with 100% certainty that the modified DLL is loading. I've modified the output to the status window to reflect where it is connecting to:

flowForm.AppendExcelLog("Connecting to " + pushServerUrl);

Any modifications like this are present in the GUI window after a recompile and subsequent load of the spreadsheet. You can see the screenshot for the new output.
NEW MODIFICATION was added to the output string. I then recompiled, moved the dll and reloaded the spreadsheet. The changes are definitely reflected in the new window that opens.
February 7th, 2011, 01:11 PM
lxnay

krohnjw,
out of curiosity, does the demo work using push.lightstreamer.com?
I'll be back to you shortly.
February 7th, 2011, 01:12 PM
krohnjw

Quote:

Originally Posted by lxnay

krohnjw,
out of curiosity, does the demo work using push.lightstreamer.com?
I'll be back to you shortly.

Yes, it does.
February 7th, 2011, 02:58 PM
lxnay

krohnjw,
to me, there might be two reasons:

- the most obvious: connectivity issues (firewall with DROP policy, etc) that make the UI freeze (UI thread is the same of Excel RTD thread, at the moment)
- more sneaky: an uncaught exception is generated at:

Code:

new ThreadStart(delegate() { lsClient.Start(pushServerUrl); }).Invoke();

Try to replace it with something like:

Code:

new ThreadStart(delegate() { try { lsClient.Start(pushServerUrl); } catch (Exception e) { flowForm.AppendExcelLog(e.Message); }; }).Invoke();
February 7th, 2011, 03:15 PM
krohnjw

Quote:

Originally Posted by lxnay

- more sneaky: an uncaught exception is generated at:

Code:

new ThreadStart(delegate() { lsClient.Start(pushServerUrl); }).Invoke();

Try to replace it with something like:

Code:

new ThreadStart(delegate() { try { lsClient.Start(pushServerUrl); } catch (Exception e) { flowForm.AppendExcelLog(e.Message); }; }).Invoke();

No exception thrown - continues to hang and excel eventually thows an alert that it's waiting for an OLE operation to complete.

Quote:

Originally Posted by lxnay

- the most obvious: connectivity issues (firewall with DROP policy, etc) that make the UI freeze (UI thread is the same of Excel RTD thread, at the moment)

Again, there is no firewall up and running. I can connect to both servers without a problem via the javascript library from this machine (Win 7 64 bit). If I run a ping or connect via HTTP I see the traffic fine in wireshark. However, with the RTD demo I continue to see not a single packet headed to the server.

Is there a significant difference in how this connects from the javascript library that would allow it to work fine using HTTP/Javascript but the connect from the .NET environment would fail?
February 7th, 2011, 04:24 PM
lxnay

The Javascript library is different from the .NET library, but the way they use the network is the same.
If, using wireshark, you don't see anything on the NIC while the RTD app loads and tries to connect, this, would make me think that there is some local application that is blocking the outgoing packets. Even if it wouldn't explain why everything works with push.lightstreamer.com.
Could you double check that there is no local firewall even? (Windows Firewall? Try to turn it off just in case).
At the same time, could you, through support@lightstreamer.com provide us some valid credentials that we can use to connect to your server through the RTD library, if possible?

Regards.
February 7th, 2011, 04:30 PM
krohnjw

Quote:

Originally Posted by lxnay

The Javascript library is different from the .NET library, but the way they use the network is the same.
If, using wireshark, you don't see anything on the NIC while the RTD app loads and tries to connect, this, would make me think that there is some local application that is blocking the outgoing packets. Even if it wouldn't explain why everything works with push.lightstreamer.com.
Could you double check that there is no local firewall even? (Windows Firewall? Try to turn it off just in case).

Already done - both the Windows firewall and all 3 party products have been disabled for the duration of testing.

Quote:

Originally Posted by lxnay

At the same time, could you, through support@lightstreamer.com provide us some valid credentials that we can use to connect to your server through the RTD library, if possible?

Regards.

Sent
February 7th, 2011, 05:14 PM
lxnay

Thanks,
at my first attempt, the application is able to connect and communicate with your server. I have a further request though, could you send us the Excel file you're using?

Regards.
February 7th, 2011, 05:18 PM
krohnjw

Quote:

Originally Posted by lxnay

Thanks,
at my first attempt, the application is able to connect and communicate with your server. I have a further request though, could you send us the Excel file you're using?

Regards.

Well, that's good news. Sent as requested.
February 7th, 2011, 05:32 PM
lxnay

I confirm. With the information you gave us, I am able to communicate with your server, which just answers: "Requested Adapter Set not available", which confirms that the communication is successful, without blocking the UI.
February 7th, 2011, 05:38 PM
krohnjw

Quote:

Originally Posted by lxnay

I confirm. With the information you gave us, I am able to communicate with your server, which just answers: "Requested Adapter Set not available", which confirms that the communication is successful, without blocking the UI.

Where is this response seen? Why do we not see any response? You've received both the source we are using as well as the Excel doc so I would assume there is some discrepancy causing us to not be able to connect.
February 7th, 2011, 05:47 PM
krohnjw

Quote:

Originally Posted by krohnjw

Where is this response seen? Why do we not see any response? You've received both the source we are using as well as the Excel doc so I would assume there is some discrepancy causing us to not be able to connect.

Aha, I just loaded the same files on a 32 bit machine and I see the Connect as well as output. The UI is not blocked.

On a 64 bit machine though I continue to see the same issues of the UI blocking and no connection attempt being made.
February 7th, 2011, 06:00 PM
krohnjw

Quote:

Originally Posted by krohnjw

Aha, I just loaded the same files on a 32 bit machine and I see the Connect as well as output. The UI is not blocked.

On a 64 bit machine though I continue to see the same issues of the UI blocking and no connection attempt being made.

Update: We have it running on 1 64 bit machine - perhaps constantly updating the lib on the machine I am developing on has mucked some things up. Let me wipe all of the registry entries and start with this working lib.

Update 2: Removing the Demo (MSI) and cleaning everything appears to have resolved whatever connectivity issues were created. We're up and running properly on both 32 bit and 64 bit machines.
February 8th, 2011, 01:47 PM
lxnay

Great!
Nice to hear that, congrats!