QuickFIX/n-启动程序在登录阶段反复抛出错误 [英] QuickFIX/n - Initiator repeatedly throw errors during Logon phase

问题描述

我在下面的此链接上使用交易客户应用程序在我的VPS服务器和经纪人服务器之一之间建立连接.

I am using the trade client application on this link below to make connection between one of my VPS server and brokers server.

http://www.quickfixn.org/tutorial/example-applications .

经过一周的努力，我终于可以轻松地建立与代理服务器的连接.

After one week of struggle, I been able to make a connection to the broker's server finally in loosely speaking.

但是，当我运行交易客户端应用程序时，在登录阶段出现此错误:

However, when I run the trade client application, at logon stage I am getting this errors:

Unable to write data to the transport connection: An existing connection was forcibly   closed by the remote host

at QuickFix.SocketInitiatorThread.ReadSome(Byte[] buffer, Int32 timeoutMilliseconds) 
in ... SoecketInitiatorThread.cs:line 170 ......

at QuickFix.SocketInitiatorThread.Read() in ... SoecketInitiatorThread.cs:line 80
......

贸易客户应用程序一直在重复登录尝试，但是，它始终仅收到相同的错误消息.

The trade client application is keeping repeating the logon attempt, however, it keeps getting the same error message only.

当然，对于像我这样的新手，使用此QuickFix/n引擎，我真的无法弄清楚出了什么问题.我可以想到的一个可能的调查领域是，我的隧道证书可能无效，因为我也是隧道程序的新手( https://www.stunnel.org ).我只是按照网站上的指示使用代理的ip地址配置pem证书，但是我不确定其目的是什么.

Of course, with newbie like me on this QuickFix/n engine, I am really unable to figure out what went wrong. One possible area of investigation I can think of is that my stunnel certificate may be invalid as I am also very new to stunnel program (https://www.stunnel.org). I only followed the instruction from website to configure pem certificate with broker's ip address but I am not 100% sure about its purpose though.

这是我放在"stunnel.conf"文件中的内容:

Here is what I put on the "stunnel.conf" file:

[FIXORDER]
client = yes
accept = external ip of VPS : port   eg.(10.160.103.65:22)
connect = broker ip address :port  eg.(102.12.124.9:444)

以下是来自Stunnel程序的已记录消息的一些记录:

Here is some record of logged message from stunnel program:

2014.11.26 17:23:44 LOG5[3348]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
2014.11.26 17:23:48 LOG5[760]: Service [FIXORDER] accepted connection from x.xx.xx.xxx:xx
2014.11.26 17:23:48 LOG5[760]: s_connect: connected xxx.x.xx.xxx:xxx
2014.11.26 17:23:48 LOG5[760]: Service [FIXORDER] connected remote server from x.xx.xxx.xxx:xxx
2014.11.26 17:23:48 LOG3[760]: SSL_connect: Peer suddenly disconnected
2014.11.26 17:23:48 LOG5[760]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket

我使用内置的自我证书应用程序使用上面的"stunnel.conf"文件构建了证书.

I built certificate using above "stunnel.conf" file using built in self certificate application.

如您所见，对于像我这样的新手来说，这有点复杂，对此问题的任何想法或提示都将不胜感激.

As you see, it is kind of complicated for newbie like me, any thought or tips on this problem will be really appreciated.

非常感谢.

亲切的问候.

M

================================================ ================================== 于27/11/2014更新

================================================================================== Updated on 27/11/2014

在这里，我将xapi1492的建议设置为冗长的调试级别之后，从Stunnel日志文件中更新错误日志.

Here I am updating my error log from Stunnel log file after I set debug verbose high taking the suggestion from xapi1492.

2014.11.27 01:10:46 LOG7[944]: Service [FIXORDER] started
2014.11.27 01:10:46 LOG5[944]: Service [FIXORDER] accepted connection from x.xxx.xxx.xxx:3667
2014.11.27 01:10:46 LOG6[944]: s_connect: connecting xx.x.xx.xx:9002
2014.11.27 01:10:46 LOG7[944]: s_connect: s_poll_wait xx.x.xx.102:9002: waiting 10 seconds
2014.11.27 01:10:46 LOG5[944]: s_connect: connected xx.x.xx.xx:9002
2014.11.27 01:10:46 LOG5[944]: Service [FIXORDER] connected remote server from x.xxx.xxx.xxx:3668
2014.11.27 01:10:46 LOG7[944]: Remote socket (FD=392) initialized
2014.11.27 01:10:46 LOG6[944]: SNI: sending servername: xxx.x.xx.xx
2014.11.27 01:10:46 LOG7[944]: SSL state (connect): before/connect initialization
2014.11.27 01:10:46 LOG7[944]: SSL state (connect): SSLv2/v3 write client hello A
2014.11.27 01:10:46 LOG3[944]: SSL_connect: Peer suddenly disconnected
2014.11.27 01:10:46 LOG5[944]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
2014.11.27 01:10:46 LOG7[944]: Remote socket (FD=392) closed
2014.11.27 01:10:46 LOG7[944]: Local socket (FD=380) closed
2014.11.27 01:10:46 LOG7[944]: Service [FIXORDER] finished (0 left)

================================================ ================================== 于28/11/2014更新

================================================================================== Updated on 28/11/2014

仍然很难找到答案，因此我决定为QuickFix客户端应用程序提供配置文件.

Still having difficult to find answer, so I decided to provide my config file for QuickFix client application.

[DEFAULT]
ConnectionType=initiator
ReconnectInterval=2
FileStorePath=store
FileLogPath=fixlog
StartTime=00:00:00
EndTime=00:00:00
UseDataDictionary=Y
DataDictionary=FIX44.xml
SocketConnectHost= xxx //my vps ip address
SocketConnectPort= xxx //my vps port //specified on stunnel
ResetOnLogon=Y
ResetOnLogout=Y
ResetOnDisconnect=Y
CheckLatency=N
LogonTimeout=10


# standard config elements

[SESSION]
BeginString=FIX.4.4
SenderCompID= xxx   //my ID
Username= xxx       //my username
Password= xxx       //my password
TargetCompID=FIXORDER
HeartBtInt=30
SocketConnectHost= xxx  //my vps ip address
SocketConnectPort= xxx  //my vps port //specified on stunnel
DataDictionary=FIX44.xml

================================================ ================================== 于28/11/2014更新

================================================================================== Updated on 28/11/2014

根据xpa1492的建议，我将Borker的IP地址和端口号放在SocketConnectHost上 和SocketConnectPort.这是我从QuickFix客户端应用程序中获得的日志消息. 似乎已建立初始连接，但登录请求可能以某种方式无效.

Taking suggestion from xpa1492, I put Borker's IP address and port number on SocketConnectHost and SocketConnectPort. Here is the log message I am getting from my QuickFix Client Application. It seems that initial connection is made but maybe logon request is not valid somehow.

<event> connecting to xxx (ip address of broker); 
<event> connection succeeded; 
<event> session reset: ResetOnLogon; 
<event> session reset ResetSetNumFlag; 
<outgoing> 8=Fix4.4 ...... ; 
<event> initiated logon request; 
<incoming> 8=FIX4.4 .....; 
<event> received logout request; 
<outgoing> 8=FIX4.4 .....; 
<event> sending logout response;

经纪人发送注销请求时来自代理的传入消息的详细信息.

Details of incoming message from brokers when they send logout request.

<incoming> 8=FIX4.4   9=63   35=5   34=1  49=FIXORDER   52=20141128-02:09:00.495   56=TargetCompID(from acceptor standing point of view=SenderID for me)   10=171

推荐答案

当FIX服务器不喜欢您的第一条消息(通常是登录消息)时，通常会断开连接.根据您得到的错误，这正是发生的情况-您连接到服务器，发送登录消息，然后服务器断开连接.

It is very common for FIX servers to drop connections when they don't like something about your first message (which is always the logon message). Based on the error you are getting, this is exactly what is happening - you connect to the server, send the Logon message and then the server drops the connection.

解决问题的正确方法是与另一端的技术支持联系，并询问他们为什么断开连接.

The right way to solve the issue is to contact tech support on the other end and ask them why they are dropping the connection.

如果这不可行，您将需要尝试做错什么.以我的经验，问题通常是序列号不匹配(标签34).大多数服务器将保留您发送的最后一个序列号(例如1)，并且在断开连接后，您会期望发送带有下一个序列号的登录消息(在此示例中为2).尝试从1开始，并在重新连接之间增加seq编号.

If this is not feasible, you will need to experiment with what might be wrong. In my experience, the problem is often a mismatch in the sequence numbers (tag 34). Most servers would maintain the last sequence number you sent (say 1) and after a disconnect would expect you to send your Logon message with the next number (2 in this example). Try starting from 1 and incrementing the seq number between reconnects.

另一个可能的问题是错误的CompID(发件人或Targer).

Another possible issue is wrong CompIDs (Sender or Targer).

更新(设置隧道和SSL证书):

UPDATE (sTunnel and SSL certificate setup):

由于您未通过SSL连接而导致服务器断开连接的可能.您的stunnel.conf文件需要如下所示:

It is possible that the server drops the connection because you are not connecting over SSL... You stunnel.conf file needs to look like this:

; Enable debug (7 is the most verbose output)
debug = 7
output = stunnel.log

[FIXORDER]
client = yes
accept = 127.0.0.1:[port number your client connects to]
connect = [fix server ip]:[fix server port]
cert =  xxx_cert.pem
key = xxx_key.pem

请注意，accept可以是127.0.0.1或VPS服务器的IP，但是首选127.0.0.1.然后，您的Fix客户端也可以仅连接到127.0.0.1(sTunnel在其中进行监听).

Note that accept can be 127.0.0.1 or the IP of your VPS server, but 127.0.0.1 is the preferred choice. Your Fix client can then also just connect to 127.0.0.1 (where sTunnel listens).

这篇关于QuickFIX/n-启动程序在登录阶段反复抛出错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！