Support Board
Date/Time: Tue, 24 Dec 2024 03:07:28 +0000
Post your pathping route to TransAct Futures server
View Count: 1509
| [2015-11-01 07:06:49] |
| User378226 - Posts: 15 |
|
Hello, I am located in Taiwan and recently encountered disconnect problems with TransAct Futures. Long story short, my connection to the brokerage would die right after the parent order gets filled, and when I log back in, the attached child orders (stop and target) were nowhere to be found. We worked with my ISP and made some route adjustment due to packet losses at 2 of the hops, and we will see this fixes the problem. While the engineers worked on this issue, I noticed that my path (old and new) to the brokerage server 208.97.219.185 in San Francisco (http://whatismyipaddress.com/ip/208.97.219.185) would route like this -- Taiwan- San Francisco - UK - San Francisco. I don't think this needs to go to UK since the brokerage and the exchange are both located within the U.S. I pinged another brokerage's US server and it just stays in the US. I emailed the engineers and my ISP to see if its possible to remove the hop to UK, and while waiting on their response, I am curious if other TransAct customers, or anyone from other locations would get this SF-UK hop, then back to SF. Please open CMD and run "pathping gatekeeper.yorkba.com" and share your results. C:\Users\Mike>pathping gatekeeper.yorkba.com Tracing route to gatekeeper.yorkba.com [208.97.219.185] over a maximum of 30 hops: 0 laptop [] 1 h254.s98.ts.hinet.net [168.95.98.254] 2 168.95.22.94 3 PCPC-3201.hinet.net [220.128.11.94] 4 TPDT-3011.hinet.net [220.128.11.54] 5 r4101-s2.tp.hinet.net [220.128.7.113] 6 r4001-s2.tp.hinet.net [220.128.11.129] 7 r11-pa.us.hinet.net [211.72.108.225] 8 ge-0-0-1.0.ejr02.pao001.flagtel.com [198.32.176.137] --- SF 9 62.216.147.66 --- UK 10 66.7.155.97 11 ge-0-0-0.den003jp02.yipes.com [66.7.147.246] 12 66.7.155.102 13 ae0-201.chi001jp01.yipes.com [209.120.214.234] 14 66.54.154.171 15 gatekeeper.yorkba.com [208.97.219.185] --- SF Date Time Of Last Edit: 2015-11-01 07:12:17
|
| [2015-11-01 10:06:17] |
| |
|
Long story short, my connection to the brokerage would die right after the parent order gets filled, and when I log back in, the attached child orders (stop and target) were nowhere to be found. We worked with my ISP and made some route adjustment due to packet losses at 2 of the hops, and we will see this fixes the problem.
Another problem that is also happening is that the TransAct bridge program was abnormally shutting down when the TransAct server closed the connection when it did not get a response back from the TransAct API after about a second, when an order fill was sent to it. TransAct needs to solve the problem with the bridge program. And also it is our position that the trading server should be much more tolerant than about a second when waiting for a client-side acknowledgment. More like 10 seconds. Trading connections we use with other trading services will only timeout after about 40 seconds and do not require acknowledgment of fills from the client-side. Only the underlying TCP protocol is relied upon to ensure the packets make it through. Perhaps the timeout should be tighter for trading, but this is what we normally use since the connection may also carry market data. The IP address of the TransAct server 208.97.219.185 is in Chicago. Use this tool here to check that: http://www.ip2location.com/demo It is possible that the actual location of 62.216.147.66 is being misidentified. Also in one of your email messages you were saying that you were going to reinstall the TransAct software and Sierra Chart. There is no need to reinstall these programs. The problem is not going to be changed by reinstalling these programs. Here is a trace we ran to the TransAct server: 3 6 ms 6 ms 6 ms ten-2-1-0-350.bdr01.alb01.akl.VOCUS.net.nz [175.
45.102.137] 4 133 ms 132 ms 132 ms ten-0-1-0-2.cor01.alb01.akl.VOCUS.net.nz [114.31 .202.38] 5 131 ms 132 ms 132 ms bundle-200.cor01.lax01.ca.VOCUS.net [114.31.202. 45] 6 134 ms 133 ms 133 ms bundle-101.bdr01.lax01.ca.VOCUS.net [114.31.199. 61] 7 131 ms 132 ms 132 ms te0-2-0-2.rcr21.lax04.atlas.cogentco.com [38.88. 197.109] 8 134 ms 134 ms 133 ms be2017.ccr22.lax01.atlas.cogentco.com [154.54.0. 238] 9 168 ms 168 ms 168 ms be2066.ccr22.iah01.atlas.cogentco.com [154.54.7. 53] 10 174 ms 173 ms 173 ms be2443.ccr22.dfw01.atlas.cogentco.com [154.54.44 .230] 11 183 ms 183 ms 183 ms be2433.ccr22.mci01.atlas.cogentco.com [154.54.3. 214] 12 194 ms 195 ms 195 ms be2157.ccr42.ord01.atlas.cogentco.com [154.54.6. 118] 13 195 ms 194 ms 195 ms be2217.ccr41.ord03.atlas.cogentco.com [154.54.24 .206] 14 195 ms 195 ms 195 ms te0-0-2-0.agr11.ord03.atlas.cogentco.com [154.54 .0.54] 15 194 ms 193 ms 194 ms 38.88.204.38 16 194 ms 194 ms 194 ms gatekeeper.yorkba.com [208.97.219.185] Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2015-11-01 10:13:37
|
| [2015-11-01 10:14:16] |
| |
|
The prior post has been revised.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
To post a message in this thread, you need to log in with your Sierra Chart account: