环境:HP unix C开发做前端,银行方;DELPHI2007,我方,两者使用TCP/IP协议进行通讯,用二次握手方式,使用三个协议通讯(一个请求包,一个请求应答包,一个确认包),由客户端主动发起,采用短连接,请求包与请求应答包是同一次连接中完成;
1.我方用IOCP做了服务端,使用D2007开发测试客户端(使用IOCP,INDY9)都能与服务端正常通讯,但与银行方不能正常通讯,只看到对方登入后就断开.
2.我方用INDY9做了服务端,使用D2007开测试客户端(IOCP,INDY9)都能正常通讯,与银行方基本能正常通讯,但常会丢掉确认包,到最后银行方发现它自己的主控程序有问题,修改了情况好转了.但间中还会收不到确认包,银行说我拒绝他;
3.我方使用delphiXE+indy10升级了上面的服务端,银行完全不能接入,出现上面1的情况.
4.我方使用DELPHI XE + TCPServer的线程阻塞模式重写了服务端,银行不能接入,出现上面1的情况.
5.现在用回原来的2的程序,银行方出现有时能发,有时不能发数据过来,直到银行方取消一句tcpnotime什么的,可以发前两个协议过来,但还是不能发确认包过来,如何处理?
我分析:UNIX下是阻塞的,所以我用IOCP完全不能通讯,但为什么TCPSERVER用线程阻塞也不能通讯.
INDY9可以,INDY10就不可以出现IOCP的现象,不是不INDY10改为像它所说的不同的context在不同的时间有不同的线程进行服务,这与IOCP类似,所以不行,INDY9是一个连接一个线程,与TCPSERVER的线程阻塞有什么区别,
本人网络知识为空,只会用控件,IOCP也是搞网上的代码改的.
现在这里向大家求救,希望大家能给一些指点我.
谢谢.

解决方案 »

  1.   

    现在大概知道这一个情况了:3.我方使用delphiXE+indy10升级了上面的服务端,银行完全不能接入,出现上面1的情况.4.我方使用DELPHI XE + TCPServer的线程阻塞模式重写了服务端,银行不能接入,出现上面1的情况.
    估计是因为编译成64位程序,类型的长度不一致,例如是DWORD==,
      

  2.   

    5.现在用回原来的2的程序,银行方出现有时能发,有时不能发数据过来,直到银行方取消一句tcpnotime什么的,可以发前两个协议过来,但还是不能发确认包过来,如何处理?
    大部分时间可以收到确认包,但确认包比过账请求总是慢21S左右.不知为何.银行方说在发确认包前Connect我这边的SERVER时,用了21S才能连上,但为什么第一个过账请求包一连就可以连上了.
      

  3.   

    d写服务端,还是采用socket的api实现比较好
    indy及别人的iocp,出了问题不好解决
      

  4.   

    我delphi编写的服务器,每次接受一次unix客户端发送的数据就会断开,这是什么原因
      

  5.   

    有可以是Unix客户端,主动断开,或等待接收返回超时断开
      

  6.   

    在这一次中,基本解决了,到时最后还是使用UDP解决.
    其中一些情况不得不说的
    1.采用TCP,是试过几天是完全正常的,三个协议在1秒内已全部完成,后来不知为什么会出现第二次协议21S的延时.
    2.后来从生产环境中移到测试环境中,也出现了正常(三个协议在1秒内已全部完成),,后来不知为什么会出现第二次协议21S(甚至是40多S)的延时.而这边的服务器没有修改过,银行对方也说没有修改,若真是这样,只怀疑是中间网络硬件的问题.
    以上两种情况,在网络抓包时都会发现服务器会有错误包发出(发了一个错误包后再重发),一般发生在第一个协议回复时.
    3.在协议出现正常时,都使用XE2+Indy10开发的服务器运行过,服务器可以收到对方给我报文,但对方收不到我所回复的报文,这个估计是与数据类型的长度有关,以后有机会才研究,相同的加密函数在对方(64位)与这边的加密结果不一样估计也是同一问题.
      

  7.   

    21S银行说是等待连入我服务器的时间.但通过抓包我这边是一回复完第一条协议后就立即自动断开的,在代码中也是这样写的,也不知何时开始是这样,之前服务器端是不会断开了,一直是按长连接来做,由客户端主动断开.但不知为什么会在应答完第一个协议时会再次ReadFromStack出现,就好像链路没有断开,但INDY尝试去读取时才发现链路是不存在的(抓包工具也发现收到TCP的断开数据包),就好像双方通讯完都断开了,但中间还存在一条链路一样.
    另外银行的网络是跳了5层的,好像是使用IP映射把信息发送过来.