0

First of all, tracert and ping to the given FIX-IP connect within 2-5 msec!

But all the tries to connect with

     $Socket = New-Object System.Net.Sockets.TcpClient $IP, $PORT

or just

    PS>telnet Fix-IP Fix-Port

get a time-out.

Is the normal socket not the right way to connect to a ( PrimeXM-) FIX-Server?

What else can I try?

I have already asked for the log-entries of their firewall for the exact time of my connection - but haven't get any answer yet.

esqew
  • 42,425
  • 27
  • 92
  • 132
gooly
  • 1,241
  • 7
  • 20
  • 38
  • 1
    If a ping/tracert succeeds, but a socket connection fails, then there is likely no TCP server running on the port that you are trying to connect to, assuming the port is not being blocked by a firewall/router. – Remy Lebeau Jul 24 '14 at 20:27
  • @gooly Any progress on below stated steps? If indeed keen on manual testing, you can most probably use `ssh-putty` on win / `sshd` on linux, setup port-forwarding for a `:` become ssh-forwarded onto a known `[Fix-IP]:[Fix-Port#]` remote target, connect to service provisioning and finally then `PS> telnet localhost port` to see a few incoming Fix-Protocol-messages ( again, check the Service-Provisioning-Entity **documentation** on ssh-GWY access details ) – user3666197 Aug 27 '14 at 05:50

1 Answers1

0

FIX-Protocol service is first of all well documented on the Service-Provisioning-Entity side

If not, that is a red-light warning.

Typical low-performance FIX-Protocol gateway is behind a fore-standing access-management/crypto-tunnel service-point.

Thus most probably your [Fix-IP]:[Fix-Port#] is aiming at rather such SSL-Tunnel / Access-Control device, than a FIX-Protocol Messaging Engine.

ToDo

Check your Service-Provisioning-Entity documentation before getting in touch with their FIX-Protocol Compliance Testing

user3666197
  • 1
  • 6
  • 50
  • 92