While the problem is not DIRECTLY related to Reuters DataLink, it does appear that when Reuters DataLink switched ISP's, users are going through a different route to get to the servers. Some users (We've had a small number of reports from Hong Kong, and South America) seem to be getting stuck at the same hop along the route. Here is a tracert excerpt:


If you open a command prompt (Start-->Run-->CMD) and type in the following:

tracert quotes.reutersdatalink.com (and then press <Enter>)

Try and see where the last successful hop is. If the last hop you see is sprintlink.net and it starts timing out, you are likely running into the same problem. We will continue to investigate this, but we really need to get tracert screenshots (as well as confirming your host IP of origin via IPCONFIG) to try and work with the parties involved in this.

Just to clarify - this is more of an Internet Backbone related issue, not a Reuters DataLink issue, although it is obviously affecting some of our customers.

Hi Please find below the output of trace and ipconfig

Tracing route to quotes.reutersdatalink.com [192.165.218.19]

over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.2.1

2 1 ms 1 ms 1 ms 115.42.174.241

3 13 ms 12 ms 12 ms 115.42.134.105

4 12 ms 13 ms 38 ms 165.21.255.34

5 13 ms 13 ms 12 ms 165.21.255.33

6 13 ms 13 ms 13 ms ge-2-0-0.woodland.singnet.com.sg [165.21.12.66]

7 13 ms 14 ms 13 ms 203.208.191.101

8 14 ms 14 ms 13 ms xe-1-0-0-0.sngtp-cr2.ix.singtel.com [203.208.183.65]

9 211 ms 211 ms 210 ms so-2-0-2-0.plapx-cr3.ix.singtel.com [203.208.149.30]

10 201 ms 201 ms 201 ms ge-7-0-0-0.plapx-dr2.ix.singtel.com [203.208.183.182]

11 216 ms 211 ms 211 ms 203.208.145.90

12 211 ms 211 ms 210 ms po9-0.palcr1.paloalto.opentransit.net [193.251.240.165]

13 281 ms 281 ms 281 ms tengige0-12-0-0.nyktr1.newyork.opentransit.net [193.251.241.14]

14 280 ms 276 ms 277 ms gi9-0-0.nykcr4.newyork.opentransit.net [193.251.132.89]

15 277 ms 277 ms 277 ms 81.52.136.57

16 286 ms 286 ms 286 ms 81.52.136.34

17 * * * Request timed out.

18 * * * Request timed out.

19 * * * Request timed out.

20 * * * Request timed out.

21 * * * Request timed out.

22 * * * Request timed out.

23 * * * Request timed out.

24 * *

ipconfig

Windows IP Configuration

Host Name . . . . . . . . . . . . : prpc01

Primary Dns Suffix . . . . . . . :

Node Type . . . . . . . . . . . . : Hybrid

IP Routing Enabled. . . . . . . . : No

WINS Proxy Enabled. . . . . . . . : No

DNS Suffix Search List. . . . . . : primpsg

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : primpsg

Description . . . . . . . . . . . : Intel(R) 82562V-2 10/100 Network Connection

Physical Address. . . . . . . . . : 00-1D-09-94-23-35

Dhcp Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

IP Address. . . . . . . . . . . . : 192.168.2.3

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 192.168.2.1

DHCP Server . . . . . . . . . . . : 192.168.2.5

DNS Servers . . . . . . . . . . . : 192.168.2.5

Primary WINS Server . . . . . . . : 192.168.2.5

Lease Obtained. . . . . . . . . . : Friday, January 15, 2010 9:31:52 AM

Lease Expires . . . . . . . . . . : Saturday, January 23, 2010 9:31:52 AM

thanks for the support and attention, regards.

Hi,

Thanks for the info and guidance. please find below the response in cmd

C:\>telnet quotes.reutersdatalink.com 7983
Connecting To quotes.reutersdatalink.com...Could not open connection to the host
, on port 7983: Connect failed

C:\>

Let me know how I can resolve this and thanks for the support. rgds..

I am having the same problem. I am in Australia. tracert result: Microsoft Windows [Version 6.0.6002] Copyright (c) 2006 Microsoft Corporation. All rights reserved. C:\Users\chipi>tracert quotes.reutersdatalink.com Tracing route to quotes.reutersdatalink.com [192.165.218.19] over a maximum of 30 hops: 1 3 ms 2 ms 2 ms mygateway1.NB5Plus4W [192.168.1.1] 2 15 ms 28 ms 13 ms syd-nxg-men-bras1-lo-20.tpgi.com.au [10.20.20.14 6] 3 20 ms 11 ms 10 ms 220-245-178-66.tpgi.com.au [220.245.178.66] 4 11 ms 12 ms 10 ms syd-nxg-men-crt2-po-5.tpgi.com.au [202.7.171.5] 5 168 ms 168 ms 172 ms if-4-0-0.core3.SQN-SanJose.as6453.net [216.6.33. 1] 6 168 ms 168 ms 167 ms if-9-0-0.mcore4.PDI-PaloAlto.as6453.net [216.6.3 3.6] 7 173 ms 169 ms 170 ms ix-1-0.mcore4.PDI-PaloAlto.as6453.net [207.45.19 6.78] 8 172 ms 173 ms * sl-crs1-sj-0-12-0-2.sprintlink.net [144.232.8.24 0] 9 174 ms 173 ms 176 ms sl-crs2-stk-0-2-2-0.sprintlink.net [144.232.24.3 3] 10 214 ms 209 ms 214 ms sl-crs2-chi-0-15-3-0.sprintlink.net [144.232.24. 50] 11 241 ms 237 ms 264 ms sl-crs2-chi-0-10-2-0.sprintlink.net [144.232.20. 119] 12 237 ms 246 ms 242 ms sl-gw29-nyc-15-0-0.sprintlink.net [144.232.13.18 ] 13 240 ms 243 ms 241 ms 144.232.168.2 14 250 ms 242 ms 239 ms 63.175.28.2 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete. I hope this issue will be resolved soon.

Hi,

as suggested by the administrator of this forum, i tried the option of authenticating the ports mentioned and still it did not solve the problem. i tried running the downloader on a different network and also from a different system. nothing seems to work out.

i guess this has some thing to do with that reuters server maintainence issue. as i received a message from reuters about their planned maintainence around jan 8 weekend and the last price update was on jan 7, 10.

either they have to work from their side to resolve the problem or we will have to look for alternatives having no other option. its 15 days without any data updates and everyone out there could easily understand whatz the implication of that.

can someone suggest for any good alternatives especially in commodities segment.

thanks and regards,

It worked yesterday evening and less than 24 hours after it is not working again.

There was an ISP changeover. The servers themselves did not move, and the large majority of customers are still getting through and downloading.

People that can get to these last hops:

13 244 ms 307 ms 306 ms 81.52.136.57
14 328 ms 307 ms 307 ms 81.52.136.34

^^--Supposedly there have been reports of fully powercycling/resetting the modems/routers in these cases has resolved the issue. Please try this to see if it helps.
-----------------------------------------------------------------------------------------------------------
For people that are getting stuck at Sprintlink.net as their last hop, this issue is still ongoing and being investigated. This has been escalated higher up in Reuters and work is definitely proceeding on this (although it obviously involves several parties, the ISP, backbone providers, etc.) and hopefully we'll have an update soon.

This is a joke. 25 days without any support on this issue. No feedback from tech support. No answer to my email to Justin. What type of company is this?

Hi All,

The problems seems to be resolved. I am able to connect to reuters and the following is the message which I have received from reuters support team followed by my IT and their IT team interaction. Wish everyone are able to connect now.

Dear all,

I believe our engineers have found the root cause of the problem. It appears the new firewall that came with the new ISP, was using an outdated Martian Block list.
We are in the process of updating this list to no longer restrict recently allocated IP blocks.


Thank you for you patience.
Lead Support Representative, MetaStock
Thomson Reuters

I believe you are encountering a different issue than the ones recently affecting some users. The tracert was a bit misleading initially and we were working with an incorrect assumption that the different "hops" listed above were the determining factor of success.

With the new ISP, there are potentially 2 routes one could travel through to get to our servers. The 63. and 81. ip address BOTH work. We have customers that have collected data successfully when the trace goes to either path. The trace will always stop at one of those two hops, regardless of one's ability to download data.

The problem you are encountering seems to be different. Basically when The DownLoader logs you in, it maintains 1 connection all the time, and an FTP connection that is re-established with each zip file.

"Logging you on to Reuters DataLink"-->Establishes a connection to our authentication server (i.e. Port 7983). This connection HAS to remain connected in order to send multiple FTP files in the next step:

"Starting Data Retrieval...Waiting for Data...etc"-->Establishes an FTP connection to a different set of servers. After each FTP transfer (we zip I believe 200 symbols per zip file) is sent, The DownLoader tries to talk with that very first connection we made at Logging on. It does this to basically say "Hey I'm done with the last FTP download, clean that up and send me the next ZIP file".

With some customers, it seems like they end up losing the connection to our authentication server. So what happens is when one of the zip files finishes, the FTP connection closes, then The DownLoader tries to talk to that authentication server. It is unable to do so, and it appears that the download is "hanging" after one of the data files was sent.

It has been very difficult to track down why this is happening to a handful of users. Hopefully with the information you provided we might be able to see more specifically what is occurring when you lose the connection.

I use a cable connection at home, and have tested downloads with over 60,000 symbols and requesting the full amount of history we have. I've never had a download failure. Every time I've done a test here at the office I've successfully collected as well. I am not mentioning this to lessen your concerns, but just to show that in a large number of cases, most users do not run into this issue. You are certainly not the only one affected by this, however.