在确定了通讯协议和报文交换格式之后，对每一个交易，还存在一个长联接和短联接的问题：发起方发起请求后是一直保持原来的联接等待对方的响应呢还是立即断链，等对方取得响应报文后由对方重新建立新的联接?若采用前一种实现方法则称为长联接，实现起来较为简单，且可靠性较高，比较适合于业务量较小且对方业务处理延迟较小的单位和场合，长联接的缺点是不能缓冲请求报文与响应报文，当交易高峰期很多请求差不多同时到达的时候会拒绝一些请求，从而影响到业务的办理。短联接则不同，一般短联接都会在内存中建立两个消息队列，一个存放所有到达的请求报文，另一个存放所有收到的响应报文;对应每一个消息对列，有一个daemon 进程(即常驻后台运行的程序)专门处理其中的每一个报文，这样就把发起请求后等待响应报文的时间去掉了(这部分时间包括对方业务处理的时间和返回的传送时间，一般占整个交易时间的80%以上)，请求daemon只管不停的把请求队列中的请求报文发出去，不需要等待任何一个响应报文的返回，而响应daemon 则专门处理收到的响应报文;这里要特别注意的是，由于业务处理系统的并发处理机制，发出去的请求报文顺序与接收到的响应报文顺序不一定相同，因而要确定一种请求报文与响应报文之间的连接方式，一般考虑用报文中某个唯一字段如主机流水号来建立两者之间的一一对应，以免造?quot;张冠李戴"，即把后一个交易的响应报文作为前一个交易的响应返回给前台;当然短联接也有其缺点：对消息队列的管理不当有可能导致响应报文严重超时，例如第三方数据库down下来了，把所有的请求报文缓冲起来，等几分钟或几十分钟后数据库恢复正常，再对缓冲的请求报文进行处理，事实上此时的处理已经无效，因为发起请求的前端早就对此笔交易作超时处理，不需要它的返回报文了。
下面简单介绍一下以socket编程的server程序和client 程序的一般处理流程：
server端：
1、通过socket()函数向系统申请一个套接字;
文章来源于领测软件测试网 https://www.ltesting.net/
