CN107222459A - 网络连接协商方法 - Google Patents

Abstract

本发明提供一种网络连接协商方法，包括：构建连接请求信息；对连接请求信息进行处理，以获取至少一个第一协议数据单元；将第一协议数据单元通过网络传输到服务端；接收服务端返回的连接响应信息，连接响应信息包括服务端是否接受描述上下文信息中的抽象语义和传输语义的判断结果；根据接收到的连接响应信息确定与服务端之间的连接是否成功建立。上述方法使客户端以统一的标准进行连接请求信息的构建，使得服务端能准确理解并判断客户端所要求的服务内容与传输语义，传输语义的确定使得双方能以同样的传输数据的编码方式进行沟通，为后续的信息传输做好准备，有效提高了信息传递与解读的准确性。

Description

网络连接协商方法

技术领域

本发明涉及计算机技术领域，尤其涉及一种网络连接协商方法。

背景技术

医学数字成像和通信(Digital Imaging and Communications in Medicine，简称DICOM)是医学图像和相关信息的国际标准，它定义了质量能满足临床需要的可用于数据交换的医学图像格式。DIMSE是DICOM Message Service Element的简称。DIMSE为对等DICOM应用实体进行医学影像及相关信息交换提供了一种应用服务元素定义(ApplicationService Element)，包括服务和协议(DIMSE Service和DIMSE Protocol)。

DICOM是随着图像化、计算机化的医疗设备的普及和医院管理信息系统，特别是图像存档和通信系统(Picture Archiving and Communication System，简称PACS)和远程医疗系统的发展应运而生的。当CT和MR等设备生成高质量的、形象直观的图像在医疗诊断中广泛使用时，由于不同的生产商不同型号的设备产生的图像各自采用了不同的格式，使得不同的设备之间的信息资源难以互相使用，医院PACS系统的实施具有很大的困难。医疗信息系统随之带来许多新的问题：如何存储数据量极大的图像并能有效地管理？不同生产商的设备能否直接连接？如何能够在不同的生产商设备之间能够共享信息资源等等。很明显这些问题的解决方法就是采用统一的标准。为此，美国放射学会和美国电器制造商协会在1983年成立了专门委员会，制定用于医学图像存储和通信的标准，提供与制造商无关的数字图像及其相关的通信和存储功能的统一格式，以促进PACS的发展，并提供广泛的分布式的诊断和查询功能。ACR-NEMA1.0版本于1985年推出，随后增加了新的数据元素并对部分内容进行修改，形成2.0版本。由于认识到标准对网络支持的不足和标准本身存在的结构性问题，ACR-NEMA结合当时的技术条件和方法对标准作了彻底的重新制定，在1993年正式公布了新的版本，命名为DICOM3.0。与原版本相比，DICOM3.0版本采用了面向对象的分析方法，定义了医学图像在存储和通信过程中的各种实体和关系，提供了对ISO-OSI(Inter-national Standard Organization-Open System Interconnection)和TCP/IP(Transmission Control Protocol/Internet Protocol)的支持，使得在医学图像应用层上可以与其它通信协议栈直接通信而不需要重新编写程序。

为了实现在不同的生产商设备之间能够共享信息资源，首先需要在不同的生产商设备(即通信模块)之间连接通信连接，以便于传输共享数据(如医学图像)，因此，亟需一种在不同通信模块之间建立通信连接的方法。

发明内容

本发明提供一种网络连接协商方法，用以解决现有技术中不同的通信模块之间无法建立通信连接的技术问题。

本发明一方面提供一种网络连接协商方法，包括：

构建连接请求信息，连接请求信息包括至少一条描述上下文信息；描述上下文信息包括用于描述服务需求的抽象语义和用于描述数据传输编码方式的传输语义；

对连接请求信息进行处理，以获取至少一个第一协议数据单元，每个第一协议数据单元包括一条描述上下文信息；

将第一协议数据单元通过网络传输到服务端；

接收服务端返回的连接响应信息，连接响应信息包括服务端是否接受描述上下文信息中的抽象语义和传输语义的判断结果；

根据接收到的连接响应信息确定与服务端之间的连接是否成功建立。

进一步的，成功建立与服务端之间的连接之后，方法还包括：

构建第一连接释放信息；

对第一连接释放信息进行处理，以获取第二协议数据单元；

将第二协议数据单元通过网络传输到服务端；

接收服务端返回的第一连接释放确认信息；

断开与服务端之间的连接。

进一步的，成功建立与服务端之间的连接之后，方法还包括：

构建第一连接终止信息；

对第一连接终止信息进行处理，以获取第三协议数据单元；

将第三协议数据单元通过网络传输到服务端；

断开与服务端之间的连接。

进一步的，对连接请求信息进行处理，以获取至少一个第一协议数据单元，具体包括：

采用DICOM上层协议对连接请求信息进行分解，以获取第一协议数据单元。

进一步的，网络包括局域网、城域网和广域网。

本发明另一方面提供一种网络连接协商方法，包括：

接收客户端发送来的至少一个第一协议数据单元；每个第一协议数据单元包括一条描述上下文信息；

对第一协议数据单元进行解析，以获取连接请求信息，连接请求信息包括至少一条描述上下文信息；描述上下文信息包括用于描述客户端服务需求的抽象语义和用于描述客户端数据传输编码方式的传输语义；

对连接请求信息中的描述上下文信息进行逐条判断，以获得连接响应信息，连接响应信息包括是否接受描述上下文信息中的抽象语义和传输语义的判断结果；

将连接响应信息分解成至少一个第四协议数据单元，并通过网络传输到客户端。

进一步的，成功建立与客户端之间的连接之后，方法还包括：

构建第二连接释放信息；

对第二连接释放信息进行处理，以获取第五协议数据单元；

将第五协议数据单元通过网络传输到客户端；

接收客户端返回的第二连接释放确认信息；

断开与客户端之间的连接。

进一步的，成功建立与客户端之间的连接之后，方法还包括：

构建第二连接终止信息；

对第二连接终止信息进行处理，以获取第六协议数据单元；

将第六协议数据单元通过网络传输到客户端；

断开与客户端之间的连接。

进一步的，对第一协议数据单元进行解析，以获取连接请求信息，具体包括：

采用DICOM上层协议对第一协议数据单元进行解析，以将接收到的第一协议数据单元还原成连接请求信息。

进一步的，对连接请求信息中的描述上下文信息进行逐条判断，以获得连接响应信息，具体包括：

对描述上下文信息进行判断，确定是否接受描述上下文信息中的抽象语义和传输语义，以获得判断结果；

构建连接响应信息，连接响应信息中包括判断结果。

本发明提供的网络连接协商方法，使客户端以统一的标准进行连接请求信息的构建，使得服务端能准确理解并判断客户端所要求的服务内容与传输语义，传输语义的确定使得双方能以同样的传输数据的编码方式进行沟通，为后续的信息传输做好准备，有效提高了信息传递与解读的准确性。

附图说明

在下文中将基于实施例并参考附图来对本发明进行更详细的描述。其中：

图1为本发明实施例一提供的网络连接协商方法的流程示意图；

图2为本发明实施例二提供的网络连接协商方法的一流程示意图；

图3为本发明实施例二提供的网络连接协商方法的另一流程示意图；

图4为本发明实施例三提供的网络连接协商方法的流程示意图；

图5为本发明实施例四提供的网络连接协商方法的一流程示意图；

图6为本发明实施例四提供的网络连接协商方法的另一流程示意图。

在附图中，相同的部件使用相同的附图标记。附图并未按照实际的比例绘制。

具体实施方式

下面将结合附图对本发明作进一步说明。

本发明实施例提供的网络连接协商方法适用于不同的生产商设备(即不同的通信模块)之间的网络连接，以下实施例将基于DICOM3.0标准对网络连接协商方法进行说明，但是本发明提供的方法并不仅限于基于DICOM3.0标准。

一般的，将主动发起连接请求信息以请求提供服务的称为客户端，将接收连接请求信息以提供服务的称为服务端。在本发明实施例中，客户端在某种情况下(如接收来自其他客户端的连接请求信息)也可作为服务端来收发信息，为其他客户端提供服务，相应的，服务端在某种情况下(如向其他服务端发送连接请求信息)也可作为客户端来收发信息，向其他服务端发送连接请求信息。

DICOM通信模块由三层组成，对应OSI七层模型中的对话层、表示层和应用层，DICOM通信模块解决的是模块的基础结构问题，规定了各层的作用与相互之间的联系。然而在构建DICOM通信模块之后，如果想要在不同对象(即生产商设备)之间进行网络通信，两者之间必须先建立连接，协商完成建立连接之后，才能进行DIMSE网络传输。

实施例一

本实施例中的执行主体为客户端。

图1为本发明实施例一提供的网络连接协商方法的流程示意图；如图1所示，本实施例提供一种网络连接协商方法，包括：

步骤101，构建连接请求信息，连接请求信息包括至少一条描述上下文信息；描述上下文信息包括用于描述服务需求的抽象语义和用于描述数据传输编码方式的传输语义。

在DICOM网络传输中，建立网络连接的两端分别是客户端和服务端，前者称为Service Class Provider，后者称为Service Class User。如果客户端和服务端之间要建立DICOM网络连接，客户端首先要构建一个连接请求信息，连接请求信息用于描述此次连接所期望的DICOM服务和相关配置。

在DICOM网络中每一个实体(包括客户端和服务端)都会有一个独一无二的名称，类似于互联网中的IP地址，称为Application Entity Title，简称AETitle，实体名称在实际应用中不超过26个字符，全部用大写字母来表示。

在构建连接请求信息时，首先需要包括客户端的实体名称(Calling AE Title)和服务端的实体名称(Called AE Title)，分别用来表示发送请求的实体和接受请求的实体。

除了客户端的实体名称和服务端的实体名称之外，连接请求信息中还需要包括描述上下文。客户端在应用层确定一个服务需求，通常用服务类(Service Class)来表达，一个Service Class中常常封装着各种方法。一个Service Class根据当中封装的方法将服务需求发送至表示层(DIMSE层)，DIMSE层便将服务需求转换为连接请求信息中的描述上下文(Presentation Context)。由于一个服务需求可能需要分解为几个步骤，因此一条连接请求信息常常包括多个描述上下文信息(至少包括一个描述上下文信息)。

描述上下文信息由以下几个部分组成：

第一个部分是描述上下文信息的ID，用于区分一条请求信息中的不同描述上下文信息，在客户端发送的连接请求信息中的描述上下文信息的ID只能是奇数，最小为1，最大是255。

第二个部分是抽象语义(Abstract Syntax)，每一条抽象语义用来描述一种客户端所期待的服务，抽象语义常常根据应用层发送来的服务需求转化而成。

第三个部分是传输语义(Transfer Syntax)，用来描述客户端希望进行的传输数据的编码方式，比如Implicit VR Little Endian是默认编码方式。

例如某用户端应用层下达了一条指令，要求获取某份血管造影照片，该指令传达到DIMSE层，DIMSE层构建的连接请求信息如表1所示：

表1

步骤102，对连接请求信息进行处理，以获取至少一个第一协议数据单元，每个第一协议数据单元包括一条描述上下文信息。

本步骤主要用于对连接请求信息进行分解，以获得一个或多个第一协议数据单元(Protocol Data Unit，简称PDU)。PDU是一种数据结构，用于DICOM网络传输。PDU结构有七种，其中的六种用于控制连接，具体的PDU结构如表2所示：

表2

名称	作用
		A-Associate-RQ PDU	进行连接请求
A-Associate-AC PDU	接受连接
		A-Associate-RJ PDU	拒绝连接
A-Release-RQ PDU	请求释放连接
		A-Release-RSP PDU	回应释放连接请求
A-Abort PDU	终止连接
		P-Data-TF PDU	传输数据

当连接请求信息构建完成之后，连接请求信息被分割为多个第一协议数据单元，每个第一协议数据单元包含一条描述上下文信息。

具体的，采用DICOM上层协议对所述连接请求信息进行分解，以获取所述第一协议数据单元。

步骤103，将第一协议数据单元通过网络传输到服务端。

通过DICOM上层协议层，第一协议数据单元在TCP Socket的基础上经过TCP网络转变为第一数据流，传输到服务端的DICOM上层协议层(如表示层)中。网络包括局域网、城域网和广域网。

步骤104，接收服务端返回的连接响应信息，连接响应信息包括服务端是否接受描述上下文信息中的抽象语义和传输语义的判断结果。

服务端接收到第一数据流后，从第一数据流中获取第一协议数据单元，并且对第一协议数据单元进行解析，还原出连接请求信息，然后对连接请求信息中的描述上下文信息进行判断，例如服务端是否能完成这些服务，决定接受还是拒绝，并且对于每一条描述上下文信息，服务端只接受一种传输语义。

对于某一条描述上下文信息，如果服务端接受了，服务端会接受其中一种传输语义并且添加到返回信息中。服务端对每一条描述上下文信息判断完成之后，会构建连接响应信息。连接响应信息包括连接请求信息中的客户端的实体名称和服务端的实体名称，还包括对每条描述上下文信息的判断结果。服务端在构建完连接响应信息之后发送给客户端。

在TCP网络中，所有的连接请求信息与连接响应信息都是经过DICOM上层协议分解并转换为A-Associate-RQ/AC PDU片段(即第一协议数据单元和第四协议数据单元，第四协议数据单元为根据连接响应信息分解后所得)后进行传输的，分解后的PDU片段(即第一协议数据单元和第四协议数据单元)能在TCP网络中快速传输，使得连接请求信息与连接响应信息得到准确快速的传递，大大提高了网络传输速度。

步骤105，根据接收到的连接响应信息确定与服务端之间的连接是否成功建立。

客户端从接收到的连接响应信息中获取每条描述上下文信息的判断结果，根据判断结果可获知服务端可接受的抽象语义和传输语义。连接响应信息中只要有一条描述上下文信息的判断结果(接受该描述上下文信息的抽象语义和传输语义)为接受，客户端与服务端之间的连接即成功建立，否则，连接建立失败。

本实施例中，客户端通过向服务端发送连接请求信息，并在连接请求信息中包括用于描述服务需求的抽象语义和用于描述数据传输编码方式的传输语义，并接收服务端反馈的连接响应信息，客户端从连接响应信息中获取服务端是否接受包含在连接请求信息中的抽象语义和传输语义的判断结果，根据判断结果来确定客户端与服务端之间的连接是否建立，只要连接响应信息中的判断结果有一个为接受，那么客户端与服务端之间的连接便成功建立，一旦两者之间的连接成功建立，表明客户端与服务端之间以相同的传输方式建立连接，以相同的传输方式建立连接为网络传输的前提。本实施中的网络连接协商方法，规定了客户端构建出的连接请求信息具有统一性，以使服务端能根据一致的解读规则解读出连接请求信息中包括的描述上下文信息，而不会出现不同客户端发送过来的连接请求信息组织方式(即连接请求信息数据结构)不同，给服务端解读连接请求信息造成较大困难的情况。

并且，本实施中的网络连接协商方法，使客户端以统一的标准进行连接请求信息的构建，使得经过标准化的信息传输与解读之后，服务端能准确理解并判断客户端所要求的服务内容(从抽象语义中获知)与传输语义，传输语义的确定使得双方(客户端与服务端)能以同样的编码方式(即传输数据的编码方式)进行沟通，为后续的信息传输做好准备，有效提高了信息传递与解读的准确性。

实施例二

本实施例是在上述实施例的基础上进行的补充说明。客户端与服务端之间建立连接，开始进行数据传输之后，如果任何一方想要中断连接有两种方式，分别为释放连接和终止连接。

如图2所示，图2为客户端发起释放连接的流程示意图。具体包括：

步骤106，构建第一连接释放信息；第一连接释放信息包括客户端的实体名称和服务端的实体名称。

步骤107，对第一连接释放信息进行处理，以获取第二协议数据单元。

将第一连接释放信息转换为A-Release-RQ PDU片段(即第二协议数据单元)。

步骤108，将第二协议数据单元通过网络传输到服务端。服务端接收并还原该第一连接释放信息之后，构建第一连接释放确认信息，并转换为A-Release-RSP PDU片段后传输回去。

步骤109，接收服务端返回的第一连接释放确认信息。

步骤110，断开与服务端之间的连接。TCP连接关闭，释放与服务端之间的网络连接。

如图3所示，图3为客户端发起终止连接的流程示意图。具体包括：

步骤106’，构建第一连接终止信息；

步骤107’，对第一连接终止信息进行处理，以获取第三协议数据单元；

步骤108’，将第三协议数据单元通过网络传输到服务端；

步骤109’，断开与服务端之间的连接。

终止连接由客户端发出，构建第一连接终止信息后，转换为A-Abort PDU片段后发送给服务端，不等到服务端确认便直接终止TCP连接。

实施例三

本实施例中的执行主体为服务端。

图4为本发明实施例三提供的网络连接协商方法的流程示意图；如图4所示，本实施例提供一种网络连接协商方法，包括：

步骤201，接收客户端发送来的至少一个第一协议数据单元；每个第一协议数据单元包括一条描述上下文信息。

客户端发送给服务端的为第一数据流，可将该第一数据流转变为第一协议数据单元，每个第一协议数据单元包括一条描述上下文信息。

步骤202，对第一协议数据单元进行解析，以获取连接请求信息，连接请求信息包括至少一条描述上下文信息；描述上下文信息包括用于描述客户端服务需求的抽象语义和用于描述客户端数据传输编码方式的传输语义。

采用DICOM上层协议对所述第一协议数据单元进行解析，以将接收到的所述第一协议数据单元还原成所述连接请求信息。连接请求信息包括至少一条描述上下文信息。该描述上下文信息的有关内容具体可参见实施例一种相应的描述，在此不再赘述。

步骤203，对连接请求信息中的描述上下文信息进行逐条判断，以获得连接响应信息，连接响应信息包括是否接受描述上下文信息中的抽象语义和传输语义的判断结果。

具体的，对描述上下文信息进行判断，确定是否接受描述上下文信息中的抽象语义和传输语义，以获得判断结果；构建连接响应信息，连接响应信息中包括判断结果。

对连接请求信息中的描述上下文信息进行判断，例如服务端是否能完成这些服务，决定接受还是拒绝，并且对于每一条描述上下文信息，服务端只接受一种传输语义。

对于某一条描述上下文信息，如果服务端接受了，服务端会接受其中一种传输语义并且添加到返回信息中。服务端对每一条描述上下文信息判断完成之后，会构建连接响应信息。连接响应信息包括连接请求信息中的客户端的实体名称和服务端的实体名称，还包括对每条描述上下文信息的判断结果。

构建的连接响应信息如表3所示，其中，Accepted和Rejected即为判断结果，Accepted表示服务端能够完成该服务，Rejected表示服务端不能够完成该服务。ImplicitVR Little Endian表示服务端选择的传输编码方式。

表3

步骤204，将连接响应信息分解成至少一个第四协议数据单元，并通过网络传输到客户端。

本实施例中，服务端通过向客户端发送连接响应信息，并在连接响应信息中包括是否接受描述上下文信息中的抽象语义和传输语义的判断结果，以便于客户端根据判断结果来确定客户端与服务端之间的连接是否建立，只要连接响应信息中的判断结果有一个为接受，那么客户端与服务端之间的连接便成功建立，一旦两者之间的连接成功建立，表明客户端与服务端之间以相同的传输方式建立连接，以相同的传输方式建立连接为网络传输的前提。本实施中的网络连接协商方法，使服务端能提供给客户端自身可接受的数据传输编码方式，以此为前提构建的连接，可避免出现不同客户端发送过来的数据传输编码方式不同，给服务端解读连接请求信息造成较大困难的情况。

实施例四

本实施例是在实施例三的基础上进行的补充说明。客户端与服务端之间建立连接，开始进行数据传输之后，如果任何一方想要中断连接有两种方式，分别为释放连接和终止连接。

如图5所示，图5为服务端发起释放连接的流程示意图。具体包括：

步骤205，构建第二连接释放信息；第一连接释放信息包括服务端的实体名称和客户端的实体名称。

步骤206，对第二连接释放信息进行处理，以获取第五协议数据单元。将第二连接释放信息转换为A-Release-RQ PDU片段(此处即为第五协议数据单元，用以与从客户端发送的第一连接释放信息中获取的第二协议数据单元相区别)。

步骤207，将第五协议数据单元通过网络传输到客户端；客户端接收并还原该第二连接释放信息之后，构建第二连接释放确认信息，并转换为A-Release-RSP PDU片段后传输回去。

步骤208，接收客户端返回的第二连接释放确认信息。

步骤209，断开与客户端之间的连接。

如图6所示，图6为服务端发起终止连接的流程示意图。具体包括：

步骤205’，构建第二连接终止信息；

步骤206’，对第二连接终止信息进行处理，以获取第六协议数据单元；

步骤207’，将第六协议数据单元通过网络传输到客户端；

步骤208’，断开与客户端之间的连接。

终止连接由服务端发出，构建第一连接终止信息后，转换为A-Abort PDU片段后发送给客户端，不等到客户端确认便直接终止TCP连接。

虽然已经参考优选实施例对本发明进行了描述，但在不脱离本发明的范围的情况下，可以对其进行各种改进并且可以用等效物替换其中的部件。尤其是，只要不存在结构冲突，各个实施例中所提到的各项技术特征均可以任意方式组合起来。本发明并不局限于文中公开的特定实施例，而是包括落入权利要求的范围内的所有技术方案。

Claims (10)

1.一种网络连接协商方法，其特征在于，包括：

构建连接请求信息，所述连接请求信息包括至少一条描述上下文信息；所述描述上下文信息包括用于描述服务需求的抽象语义和用于描述数据传输编码方式的传输语义；

对所述连接请求信息进行处理，以获取至少一个第一协议数据单元，每个所述第一协议数据单元包括一条所述描述上下文信息；

将所述第一协议数据单元通过网络传输到服务端；

接收所述服务端返回的连接响应信息，所述连接响应信息包括所述服务端是否接受所述描述上下文信息中的抽象语义和传输语义的判断结果；

根据接收到的所述连接响应信息确定与所述服务端之间的连接是否成功建立。

2.根据权利要求1所述的网络连接协商方法，其特征在于，成功建立与所述服务端之间的连接之后，所述方法还包括：

构建第一连接释放信息；

对所述第一连接释放信息进行处理，以获取第二协议数据单元；

将所述第二协议数据单元通过网络传输到所述服务端；

接收所述服务端返回的第一连接释放确认信息；

断开与所述服务端之间的连接。

3.根据权利要求1或2所述的网络连接协商方法，其特征在于，成功建立与所述服务端之间的连接之后，所述方法还包括：

构建第一连接终止信息；

对所述第一连接终止信息进行处理，以获取第三协议数据单元；

将所述第三协议数据单元通过网络传输到所述服务端；

断开与所述服务端之间的连接。

4.根据权利要求1所述的网络连接协商方法，其特征在于，对所述连接请求信息进行处理，以获取至少一个第一协议数据单元，具体包括：

采用DICOM上层协议对所述连接请求信息进行分解，以获取所述第一协议数据单元。

5.根据权利要求1所述的网络连接协商方法，其特征在于，所述网络包括局域网、城域网和广域网。

6.一种网络连接协商方法，其特征在于，包括：

接收客户端发送来的至少一个第一协议数据单元；每个所述第一协议数据单元包括一条描述上下文信息；

对所述第一协议数据单元进行解析，以获取连接请求信息，所述连接请求信息包括至少一条描述上下文信息；所述描述上下文信息包括用于描述客户端服务需求的抽象语义和用于描述客户端数据传输编码方式的传输语义；

对所述连接请求信息中的描述上下文信息进行逐条判断，以获得连接响应信息，所述连接响应信息包括是否接受所述描述上下文信息中的抽象语义和传输语义的判断结果；

将所述连接响应信息分解成至少一个第四协议数据单元，并通过网络传输到所述客户端。

7.根据权利要求6所述的网络连接协商方法，其特征在于，成功建立与所述客户端之间的连接之后，所述方法还包括：

构建第二连接释放信息；

对所述第二连接释放信息进行处理，以获取第五协议数据单元；

将所述第五协议数据单元通过网络传输到所述客户端；

接收所述客户端返回的第二连接释放确认信息；

断开与所述客户端之间的连接。

8.根据权利要求6或7所述的网络连接协商方法，其特征在于，成功建立与所述客户端之间的连接之后，所述方法还包括：

构建第二连接终止信息；

对所述第二连接终止信息进行处理，以获取第六协议数据单元；

将所述第六协议数据单元通过网络传输到所述客户端；

断开与所述客户端之间的连接。

9.根据权利要求6所述的网络连接协商方法，其特征在于，对所述第一协议数据单元进行解析，以获取连接请求信息，具体包括：

采用DICOM上层协议对所述第一协议数据单元进行解析，以将接收到的所述第一协议数据单元还原成所述连接请求信息。

10.根据权利要求6所述的网络连接协商方法，其特征在于，对所述连接请求信息中的描述上下文信息进行逐条判断，以获得连接响应信息，具体包括：

对所述描述上下文信息进行判断，确定是否接受所述描述上下文信息中的抽象语义和传输语义，以获得判断结果；

构建所述连接响应信息，所述连接响应信息中包括判断结果。