CN101777012B - 一种三维图像服务器多任务管理调度方法 - Google Patents
一种三维图像服务器多任务管理调度方法 Download PDFInfo
- Publication number
- CN101777012B CN101777012B CN 200910239520 CN200910239520A CN101777012B CN 101777012 B CN101777012 B CN 101777012B CN 200910239520 CN200910239520 CN 200910239520 CN 200910239520 A CN200910239520 A CN 200910239520A CN 101777012 B CN101777012 B CN 101777012B
- Authority
- CN
- China
- Prior art keywords
- dimensional image
- task
- managing
- image server
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Processing Or Creating Images (AREA)
Abstract
本发明公开了一种三维图像服务器多任务管理调度方法，包括步骤：A1.三维图像服务器与至少一个客户端通过私有通信协议分别建立命令通道连接和数据通道连接；A2.在所述三维图像服务器中建立相应的命令通道处理进程、数据通道处理进程和任务处理进程，并开辟进程间通信共享内存区；A3.所述命令通道处理进程与所述客户端传递交互命令和操作参数；A4.所述任务处理进程根据所述操作参数进行图像三维重建并生成三维图像数据；A5.所述数据通道处理进程向所述客户端发送所述三维图像数据。本发明三维图像服务器多任务管理调度方法采用多进程和双通道与客户端进行通信，提高了三维图像服务器的通信服务稳定性。
Description
技术领域
本发明涉及通信技术领域，具体涉及一种三维图像服务器多任务管理调度方法。
背景技术
三维可视化技术对于临床医学的精确诊断以及手术计划越来越重要的作用。先进的医学影像设备是先进的医学图像处理与分析的基础，特别是多排CT(computed tomography，计算机断层成像术)与高场MR(Magnetic resonance imaging，磁共振)带给临床的是：更快的扫描速度(0.5S)、更高的图像分辨率(0.3MM)、更多的单个病人数据量(＞2000层)、更广泛的临床应用，与此同时，需要更丰富的软件处理能力。在医学诊断中，医务人员通过观察多组二维(2D)断层图像，在大脑中进行三维(3D)数据的重建，以此来确定病变体的空间结构。这就难以准确确定病变体的空间位置、大小、几何形状及与周围生物组织之间的关系。因此，从一系列二维断层图像生成三维图像在医学观察中有越来越迫切的需要。对于过去长期使用单排CT的医生来说，先进影像设备不但硬件的提升，也是诊断技术、诊断方式上的革命性的改变。如果依然延续过去单排CT或普通MR的扫描、处理、诊断方式，在很大的程度上，不能发挥设备革命性的升级对诊断的重大影响。要充分体现先进影像设备的临床应用价值，挖掘海量数据的诊断内容，就需要从常规的2D阅片工作站与时俱进提升到3D专业工作站。医生可以从大量图像数据中，找到真正有价值的图像，减少诊断信息上的疏漏。除放射科室以外，3D医疗影像在手术计划以及教学演示等，同样起着相当重要的作用。医生依靠先进的PACS(Picture Arching and Communication System)系统和数字化3D专业软件，可以更直观、更精确、多角度来观察组织形态结构，真正享受由专业软件带来的快速、有效、直观的工作环境。3D专业工作站系统将为临床阅片提供新一代的解决方案。在兼容传统2D阅片工作站的基础上，提供更适合医生认识与思维的诊断信息。
根据医学图像精度高、内容丰富的要求，光线跟踪算法(Raycastting)是所有三维图像重建中最合适的重建方式。光线跟踪算法的特点是图像质量很高，但其中采样、三线性插值等的计算量很大，使得图像重建速度慢。虽然已经有了很多优化方法，要进行实时显示，普通计算机的计算能力还是无法达到要求，再加上图像数据量非常庞大，光从PACS存储服务器将二维断层图像数据加载到阅片工作站就要花很多时间，因此现有技术的阅片工作站并不适合进行三维图像重建。
三维图像服务器任务处理方式和单机三维图像工作站不同，必须支持多客户端的请求任务，为了实现多任务并行处理，常用的通信服务处理方法是启动一个主线程实时监听客户端发过来的请求，当接收到一个请求后主线程会新启动一个子线程负责处理该客户端的请求任务，然后主线程继续监听请求，子线程完成客户端的处理任务后将结果还回给客户端然后断开连接，子线程结束任务销毁线程占用资源。使用这种方法可以满足并行处理的要求，但是用于三维处理的二维断层图像数据都非常庞大，一般情况下标准的三维体数据分辨率在X：512，Y：512，Z：512像素以上，医学图像数据每个像素最小12位灰阶值，也就是每个像素要占两个字节，一个用户连接到三维图像服务器打开一个检查，三维图像服务器内存就要开辟一个512*512*512*2＝256MB的空间用来存放数据体，再加上可视化重建需要分配的辅助空间，如果将所有连接进来的用户都放在一个进程中进行处理，三维服务进程占用的内存将非常大，对操作系统的管理能力要求非常高。再加上线程虽然相互独立运行，可使用的资源是共用的，他们之间有可能存在相互影响。多个任务同时进行处理过程中，有一个任务处理发生错误无法执行下去的时候有可能会影响到其它任务的执行，由于各种错误的累积必然会出现一些不可预知情况的发生，最后可能导致三维图像服务器服务程序崩溃。
发明内容
本发明要解决的技术问题是提供一种三维图像服务器多任务管理调度方法，克服现有技术服务器通信服务单纯采用子线程与每个客户端进行通信，容易导致通信服务不稳定的缺陷。
本发明为解决上述技术问题所采用的技术方案为：
一种三维图像服务器多任务管理调度方法，包括步骤：
A1、三维图像服务器与至少一个客户端通过私有通信协议分别建立命令通道连接和数据通道连接；
A2、在所述三维图像服务器中建立相应的命令通道处理进程、数据通道处理进程和任务处理进程，并开辟进程间通信共享内存区；
A3、所述命令通道处理进程与所述客户端传递交互命令和操作参数；
A4、所述任务处理进程根据所述操作参数进行图像三维重建并生成三维图像数据；
A5、所述数据通道处理进程向所述客户端发送所述三维图像数据。所述的三维图像服务器多任务管理调度方法，其中所述步骤A2包括步骤：建立管理进程，由所述管理进程开辟所述进程间通信共享内存区。
所述的三维图像服务器多任务管理调度方法，其中所述步骤A2包括步骤：所述管理进程为所述命令通道处理进程、所述数据通道处理进程和所述任务处理进程在所述进程间通信共享内存区内分配内存资源。
所述的三维图像服务器多任务管理调度方法，其中所述步骤A2包括步骤：所述管理进程在所述进程间通信共享内存区内设置进程状态表，所述进程状态表用于标记进程的状态。
所述的三维图像服务器多任务管理调度方法，其中所述步骤A2包括步骤：所述管理进程在所述进程间通信共享内存区内设置进程消息表，所述进程消息表用于存储进程间进行通信的消息内容。
所述的三维图像服务器多任务管理调度方法，其中所述步骤A2包括步骤：所述管理进程在所述进程间通信共享内存区内设置子进程属性信息结构，所述子进程属性信息结构用于标记进程的相关信息。
所述的三维图像服务器多任务管理调度方法，其中所述步骤A2包括步骤：所述管理进程在所述进程间通信共享内存区内设置命令通道信息结构。
所述的三维图像服务器多任务管理调度方法，其中所述步骤A2包括步骤：所述管理进程在所述进程间通信共享内存区内设置数据通道信息结构。
所述的三维图像服务器多任务管理调度方法，其中所述步骤A2包括步骤：所述管理进程在所述进程间通信共享内存区内设置管理进程属性信息结构。
所述的三维图像服务器多任务管理调度方法，其中所述管理进程预先启动至少一个命令通道处理进程、至少一个数据通道处理进程和至少一个任务处理进程。
本发明的有益效果：本发明三维图像服务器多任务管理调度方法采用多进程和双通道与客户端进行通信，提高了三维图像服务器的通信服务稳定性。
附图说明
本发明包括如下附图：
图1为本发明三维图像处理过程示意图；
图2为本发明命令通道交互过程示意图；
图3为本发明数据通道交互过程示意图；
图4为本发明为三维图像服务器多任务管理调度方式示意图；
图5为本发明双通道处理流程图；
图6为本发明三维图像服务器设置管理进程示意图；
图7为本发明进程间通信共享内存区内的信息结构示意图；
图8为本发明三维图像服务器管理进程流程图；
图9为本发明三维图像服务器任务处理流程图；
图10为本发明实施例管理进程加载示意图；
图11为本发明实施例命令通道和数据通道日志窗口示意图；
图12为本发明实施例任务处理进程加载示意图；
图13为本发明实施例客户端进程加载示意图；
图14为本发明实施例客户端调整参数示意图。
具体实施方式
下面根据附图和实施例对本发明作进一步详细说明：
如图1所示，影像设备负责采集数据，将数据发送到存储服务器进行归档，存储服务器对数据归档后将需要进行重建的数据加载到三维图像服务器进行预处理，当三维阅片工作站(客户端)需要进行阅片的时候向三维图像服务器发出处理请求，三维图像服务器接收到处理任务后将数据加载到内存中进行计算，然后将计算结果还回给三维阅片工作站进行显示。
为了实现上述三维图像处理方式，首先必须在三维图像服务器与三维阅片工作站之间建立私有通信协议，实现相互间的信息交互。为此在TCP/IP协议之上建立了一个应用层协议3DAP(3D Access Protocol)，通过该应用层协议3DAP就可以将客户端的操作请求提交到三维图像服务器进行处理，三维图像服务器同样可以将计算结果返回到客户端进行显示。
如表1所示，首先定义一组服务类：
表1
| 服务类 | 说明 |
| FM_CONTROL | 建立连接请求服务 |
| FM_EXECUTE | 执行一条操作命令 |
| FM_EXECUTE_RESPONSE | 返回命令处理结果 |
| FM_GET_FILE | 获取流数据 |
| FM_GET_FILE_RESPONSE | 返回获取流数据结果 |
| FM_PUT_FILE | 提交流数据 |
| FM_PUT_FILE_RESPONSE | 返回提交流数据结果 |
如表2所示，有了服务类定义后，还需要为每一个服务类定义相应的处理消息，用与确认处理的具体情况：
表2
| 消息定义 | 说明 |
| FMMC_CONNECT | 客户请求连接 |
| FMMC_ACCEPT | 接受客户连接 |
| FMMC_REJECT | 拒绝客户连接 |
| FMMC_DISCONNECT | 客户/服务器要求断开连接 |
| FMMC_ECHO | 测试服务器是否活动 |
| FMMC_ECHO_SUCC | 服务器返回客户端表示连接通畅 |
| FMMC_SUCCESS | 传送数据正常 |
| FMMC_FAIL | 传送数据错误 |
| FMMC_NULL | 传送数据为空值，临时数据，空值属正常情况 |
| FMMC_RETURN_PARAM | 传送数据有返回信息 |
有了应用层协议3DAP，客户端和三维图像服务器之间就可以进行灵活的数据交换。具体的操作主要分为五大步骤：
第一步：建立连接，即建立底层的通信管道。按照前面描述的规则和定义，客户端使用上层服务，发送关联建立请求FM_CONTROL(FMMC_CONNECT)到三维图像服务器，三维图像服务器接受该请求，三维图像服务器验证客户端的合法性后建立接受/拒绝FM_CONTROL(FMMC_ACCEPT/FMMC_REJECT)响应。如果成功，即客户端收到FM_CONTROL(FMMC_ACCEPT)，则表示客户端和三维图像服务器之间的关联建立成功。
第二步：发送执行命令操作，即客户端向三维图像服务器发送执行命令。客户端遵循双方协议，向三维图像服务器发出FM_EXECUTE请求，将用户操作参数打包到FM_EXECUTE服务类中，提交到三维图像服务器上，如果三维图像服务器成功接收命令，即客户端收到FM_EXECUTE_RESPONSE(FMMC_SUCCESS)，如果不成功客户端收到FM_EXECUTE_RESPONSE(FMMC_FAIL)。
第三步：提交流数据操作，即客户端向三维图像服务器发送二进制数据流。由于执行命令一般提交数据量较小的参数，当客户端需要向三维图像服务器提交较大的二进制数据时，专门为大颗粒数据提交定义了一个命令。当客户端需要向三维图像服务器发出二进制数据时发出FM_PUT_FILE，同时将数据内容打包到服务类，提交到三维图像服务器，如果三维图像服务器成功接收命令，即客户端收到FM_PUT_FILE_RESPONSE(FMMC_SUCCESS)，如果不成功客户端收到FM_PUT_FILE_RESPONSE(FMMC_FAIL)。
第四步：获取流数据操作，即客户端向三维图像服务器请求获取数据流。客户端提交的各种处理命令后，三维图像服务器是以流水线的方式进行处理，处理完的数据由客户端每次请求获取数据的时候返回结果，首先客户端会发出FM_GET_STREAM获取数据的请求，如果三维图像服务器上有已经处理完成的数据会将内容返回给客户端，客户端接收到FM_GET_FILE_RESPONSE(FMMC_RETURN_PARAM)，如果未有处理结果，三维图像服务器会返回FM_GET_FILE_RESPONSE(FMMC_SUCCESS)。
第五步：释放关联，通信完成后，双方通过发送关联释放请求/响应FM_CONTROL(FMMC_DISCONNECT)来释放此次连接。
如图2、图3、图4和图5所示，按照上面的交互方式可以看出发送执行命令操作FM_EXECUTE、数据提交操作FM_PUT_FILE、获取数据操作FM_GET_FILE之间并没有关系，如何能将几个服务类联系起来呢？由于三维图像服务器的计算时间比客户端提交命令的时候要慢，所以不可能每次都等待三维图像服务器处理完成一次命令后再提交新的请求任务，这样的话客户端操作起来将会感觉交互的及时性不够好。为了避免这个问题，本发明使用流水作业的方法，在三维图像服务器和客户端之间同时建立两个网络通道：命令通道和数据通道，命令通道专门用来接收客户端提交的命令，数据通道专门用来返回三维图像服务器的处理结果，命令通道和数据通道使用异步处理的模式。
有了命令通道和数据通道后客户端用户交互线程就可以通过客户端的命令通道接口实时向三维图像服务器提交数据，三维图像服务器通过命令通道接收到任务进行处理，然后将处理后的数据内容通过数据通道返回给客户端，客户端数据通道接收到数据后通知用户交互层进行显示。上述操作过程完成用户需要的操作以及显示效果，命令通道和数据通道在物理上是两个完全独立的连接，使用的私有通信协议也是相同的，当客户端与三维图像服务器建立连接的时候会同时打开这两个连接通道，三维图像服务器如何来识别这两个通道是哪一个呢？为了识别两个通道，在客户端建立连接成功后命令通道会发出注册命令通道命令和当前用户注册编号用来标识命令通道，数据通道会发出数据通道注册命令和用户注册编号，有了统一的用户编号和不同的注册命令就可以将几个对象有效的联系起来。
如图6和图7所示，采用多个进程来实现并行处理方案。首先将每一个网络通道独立一个进程，每一个处理任务独立一个进程，当用户连接到服务器上进行三维处理的时候，应该由一个命令通道进程、一个数据通道进程、一个任务处理进程共同组成处理流程。使用这种方法来响应客户端的任务处理，处理过程中出现的任何一个环节发生故障，都可以单独关闭，重新启用一个进程来代替之前故障进程的工作，这样就不会影响到整体的稳定性了。
如何将几个松散的进程有效的结合起来以流水线的方式对用户的请求进行操作呢？因为命令通道、数据通道和处理任务都已经独立为进程，所以已经完成了独立作业的模式，只要各个进程有效地进行通信就可以满足三维处理流水线设计的要求。首先各进程要进行联系必须要有一个统一的进程间通信共享内存区进行数据传递，然后为每个客户端连接到三维图像服务器的时候都分配了一个唯一的标识，当命令通道第一次连接到三维图像服务器的时候将这个标识注册到进程间通信共享内存区，注册标识的时候可以同时绑定一个任务处理进程，数据通道连接到三维图像服务器的时候就可以根据标识信息和对应的任务处理进程进行关联。根据上述说明，本发明方法的实现主要是分成三部分：通道进程(Pipeline Process)(包括命令通道进程和数据通道进程)、进程间通信共享内存区(Shared Memory)、任务处理进程(Task Process)。但是这三部分如何联系起来以及如何避免通道进程相互抢夺资源呢？为了将这三部分有效的组织起来，还需要再引入一个管理进程(ManageProcess)，由管理进程来对资源进行有效的分配，
因为系统在运行的时候会为每个进程分配不同的内存区域，对不同进程来说，它们具有独立的数据空间，要进行数据传递需要分配一个进程间通信共享内存区(Shared Memory)。首先在启动管理进程的时候通过系统函数CreateFileMapping创建一个进程间通信共享内存区，通过MapViewOfFile将内存区映射到进程地址中，然后定义四个数据结构，分别是：命令通道信息结构、数据通道信息结构、子进程属性信息结构和管理进程属性信息结构，记录管理进程属性信息、进程选择属性信息及命令通道和数据通道数据交换信息，同时在进程间通信共享内存区内设置进程状态表，将四个数据结构映射到进程间通信共享内存区，这样进程间就可以知道各自的状态，以便进行下一步的操作。
进程状态表如表3所示：
表3
命令通道信息结构：
struct LChildCommandData
{
HWND Handle；//进程返回数据对象句柄
int Command；
bool IsLastFragment；//是否为结尾数据
UINT32 ParamSize；//参数大小
UINT32 DataSize；//数据大小
char Data[0x8000]；
}；
数据通道信息结构：
struct LChildReturnData
{
int DataState；//数据状态
bool IsLastFragment；//是否为结尾数据
UINT32 ParamSize；//参数大小
UINT32 DataSize；//数据大小
char Data[0x80000]；
}；
子进程属性信息结构：
struct LChildProcInfo
{
LProcState State；//进程当前状态
HANDLE ProcessHandle；//进程句柄
UINT32 ProcessId；//进程编号
char ObjectId[20]；//处理对象编号
DATE OpenTime；//进程打开时间
DATE ExecuteTime；//进程最后一次执行命令的时间
DATE SuspendTime；//进程最后一次挂起时间
UINT32 CommandProcId；//发送命令进程编号
UINT32 ReturnProcId；//返回数据进程编号
LChildCommandData CommandData；//进程命令数据内容
LChildReturnData ReturnData；//进程返回数据内容
}；
管理进程属性信息结构：
strct LParentProcInfo
{
HWND Handle；//父进程对象句柄
int IniProcCount；//子进程初始启动数
int MaxProcCount；//子进程可启动总数
}；
实现了对进程状态的记录后还需要在进程间通信共享内存区中设置一组用于进程间通信的消息命令。
进程消息表如表4所示：
表4
| 消息命令 | 命令描述 |
| WM_PROCESS_OPEN | 进程已经打开，向父进程发出通知 |
| WM_PROCESS_CLOSE | 进程已经关闭，向父进程发出通知 |
| WM_PROCESS_EXECUTE | 向父进程发出通知，进程已经开始执行操作，需要重新启动一个新进程进行监听 |
| WM_PROCESS_SUSPEND | 向父进程发出通知，进程已经挂起 |
| WM_PROCESS_Stop | 向子进程发出通知，要求停止处理 |
| WM_PROCESS_SELECT | 向父进程发出通知，要求选择一个处理进程 |
| WM_SEND_COMMAND | 发送参数令命 |
如图8和图9所示，管理进程启动后将进程消息句柄记录在管理进程属性信息结构中。为了避免启动任务进程影响系统的运行效率，在启动管理进程后预先启动至少一个命令通道处理进程、至少一个数据通道处理进程和至少一个任务处理进程。使用CreateProcess函数启动进程，函数调用结束后返回进程ID号，找出子进程属性信息结构中未记录进程信息的位置，将内容写入该位置，同时将进程设置为psInit状态表示该进程正在启动中，还不能接收任务。
任务处理进程启动后通过系统函数OpenFileMapping打开管理进程创建的进程间通信共享内存区，通过MapViewOfFile将内存区映射到进程地址中，这样任务处理进程就可以访问子进程属性信息结构中的信息。使用GetCurrendProcessId获取该进程ID找出子进程属性信息结构中记录该进程的位置，将进程状态修改为psSuspend，同时将当前时间写入SuspendTime，说明任务处理进程已经启动成功，可以执行任务。同时使用PostMessage向管理进程发出WM_PROCESS_OPEN消息，通知管理进程可以为任务处理进程分配任务。
管理进程进入等待任务求请状态，实时检测命令通道处理进程、数据通道处理进程。当命令通道处理进程接收到一个用户任务请求时，首先根据子进程属性信息结构，判断该通道是否已经分配了处理资源，如果CommandProcId等于当前命令通道进程号，说明已经分配了资源，直接向任务处理进程发出处理请求，如果未分配资源，向管理进程发出WM_PROCESS_SELECT消息，将当前命令通道进程编号发送给管理进程，请求分配一个可用资源进行处理，发出消息后通道处理进程等待管理进程分配的资源，管理进程接收到WM_PROCESS_SELECT消息后，在子进程属性信息结构中找出一个挂起的进程做为当前的处理对象，将命令进程编号写入CommandProcId。命令通道进程检测到CommandProcId与当前进程编号匹配后将当前客户端发过来的ObjectId写入进程间通信共享内存区，完成客户端的连接请求，同时将State状态设置为psExecute执行状态，当前时间写入ExecuteTime。如果未找到可用任务处理进程，管理进程将启动一个新的任务处理进程来处理，启动新的任务处理进程的同时将State状态设置为psAction击活状态，等新的任务处理进程启动成功后将其改为psExecute。
命令通道连接成功后，数据通道也将连接，根据检测ObjectId来配对处理的资源，如果匹配成功，将数据通道进程编号写入ReturnProcId，数据通道注册成功后客户端将保持与三维图像服务器的连接状态，不断向三维图像服务器发来获取数据的消息，如果三维图像服务器有处理后的数据将返回内容，如果延迟一定时间未有数据将返回一个空消息，用于保持两边的连接状态，每次三维图像服务器接收到数据获取消息的时候都将刷新ExecuteTime信息，这样管理进程将可以知道该连接还处于正常状态。通过该方法命令通道进程、数据通道进程和任务处理进程就可以有效的联系起来。客户端注册成功后就可以向任务处理进程发出各种操作请求。请求命令内容分别在LChildCommandData信息结构填写Command：处理命令信息，ParamSize：参数内容大小，DataSize：二进制数据大小，Data：数据内容，数据内容首先写入参数内容然后是二进制数据内容(参数)+(二进制数据)。如果Data定义的最大空间不能放下输入的参数内容和二进制数据，可以采用多次填入数据的方法来实现大数据的输入，用IsLastFragment来识别数据是否传输完成。将信息写入后向任务处理进程发出WM_SEND_COMMAND命令，通知任务处理进程对该命令进行处理。对应的任务处理进程检测到处理任务后执行相应的计算，计算结果写入LChildReturnData信息结构中，写入方法与命令参数传递方式基本相同。数据通道检测到数据后将内容读取出来返回给客户端。当客户端结束处理后会向管理进程发出释放请求WM_PROCESS_CLOSE消息，管理进程接收到消息后为了保证系统的稳定工作将关闭当前任务处理进程。关闭任务处理进程后为了可以接收其它客户端的任务，管理进程将重启一个新的进程来代替旧任务处理进程。当客户端发生错误异常退出，三维图像服务器无法接收到关闭处理命令的通知，管理进程通过检测ExecuteTime的刷新，如果发现超过一定时候没有变化就可以知道客户端已经断开，直接将对应任务处理进程关闭。
具体实例
如图10所示，在客户端和服务端运行五个程序，分别是客户端的测试进程Test3DClient.exe用来响应用户的操作任务和处理后的显示效果，服务端的I3DServer.exe用来作为管理进程，I3DPipeline.exe用于与客户端进行交互的通道进程，I3DChild.exe为处理进程用来进行核心计算。如图10所示启动了5个任务处理进程来响应客户端的请求，其中有两个任务处理进程正在处理用户的操作。
根据DICOM标准定义，每个检查可以分成多个序列，每个序列可分成多幅图像，三维可视化的数据是由一个序列的一组二维断层图像数据组成。检查、序列、图像在标准里面都定义了唯一的UID标识，客户端通知三维图像服务器重建一组二维序列图像，本发明使用两级UID，也就是客户端发送检查UID和序列UID，三维图像服务器根据这两个索引值打开数据内容。
例如：首先客户端配置好服务IP地址：192.168.141.82，端口：4450，连接上服务器后，检查号输入1.2.840.113704.1.111.5600.1107858801.1，序列号输入1.2.840.113704.1.111.5600.1107859570.17，点打开按扭
首先客户端会打开两个线程，分别是命令通道(SendCommandChannel)和数据通道(ReadDataChannel)：
Open SendCommandChannel
Connect<IP:192.168.141.82Port:4450>
<--SEND MESSAGE HEADER(FM_CONTROL，FMMC_CONNECT)
-->RECEIVE MESSAGE HEADER(FM_CONTROL，FMMC_ACCEPT)
Open ReadDataChannel
Connect<IP:192.168.141.82Port:4450>
<--SEND MESSAGE HEADER(FM_CONTROL，FMMC_CONNECT)
-->RECEIVE MESSAGE HEADER(FM_CONTROL，FMMC_ACCEPT)
建立连接后客户端会通过命令通道向三维图像服务器发出当前用户编号：
<--SEND MESSAGE HEADER(FM_EXECUTE，FMMC_CONNECT)
<--SEND FILE PARAMETER
Command:comOpenObject
Accessory:0
Parameter:STRING＝38942B2D56BB49
同时数据通道也将发出相同的用户编号来进行注册：
<--SEND MESSAGE HEADER(FM_EXECUTE，FMMC_CONNECT)
<--SEND FILE PARAMETER
Command:comLoginObject
Accessory:0
Parameter:STRING＝38942B2D56BB49
服务端接收到一个用户任务请求时，首先判断处理进程属性信息结构，该通道是否已经分配了处理资源，如果CommandProcId等于当前命令通道进程号，说明已经分配了资源，直接向处理进程发出处理请求，如果未分配资源，向管理进程发出WM_PROCESS_SELECT消息，将当前命令通道进程编号发送给管理进程，请求分配一个可用资源进行处理，发出消息后命令通道将等待管理进程分配的资源，管理进程接收到WM_PROCESS_SELECT消息后，在处理子进程信息表中找出一个挂起的进程做为当前的处理对象，将命令进程编号写入CommandProcId。命令通道进程检测到CommandProcId与当前进程编号匹配后将当前客户端发过来的ObjectId写入交换区，完成客户端的连接请求，同时将State状态设置为psExecute执行状态，同时状当前时间写入ExecuteTime。如果未找到可用任务处理进程，系统将启动一个新的任务处理进程来处理，启动进程的同时将State状态设置为psAction击活状态，等进程启动成功后将其改为psExecute。数据通道连接到服务端，根据检测ObjectId来配对处理的资源，如果匹配成功，将数据通道进程编号写入ReturnProcId，数据通道注册成功后客户端将保持与服务器的连接状态，不断向服务端发来获取数据的消息，如果服务端有处理后的数据将返回内容，如果延迟一定时间未有数据将返回一个空消息，用于保持两边的连接状态，每次服务端接收到数据获取消息的时候都将刷新ExecuteTime信息，这样管理进程将可以知道该连接还处于正常状态。
连接成功后命令通道向服务器发出打开数据体命令：
<--SEND MESSAGE HEADER(FM_EXECUTE，FMMC_CONNECT，3V)
<--SEND FILE PARAMETER
Command:comOpenVolume
Accessory:0
Parameter:STRING＝1.2.840.113704.1.111.5600.1107858801.1；STRING＝1.2.840.11
3704.1.111.5600.1107859570.17；
-->RECEIVE MESSAGE
HEADER(FM_EXECUTE_RESPONSE，FMMC_SUCCESS)
服务端命令通道接收到命令后内容填写在LChildCommandData信息结构中。将comOpenVolumn填写Command信息，参数大小填写在ParamSize，打开数据的检查号和序列号填写到Data中。将信息写入后向处理进程发出WM_SEND_COMMAND命令，通知任务处理进程对该命令进行处理。
客户端通过数据通道发出读取数据请求：
<--SEND MESSAGE HEADER(FM_GET_FILE，FMMC_CONNECT)
<--SEND FILE PARAMETER
Command:comGetImageData
Accessory:0
-->RECEIVE MESSAGE HEADER(FM_GET_FILE_RESPONSE，FMMC_ACCEPT)
-->RECEIVE FILE PARAMETER
Command:comGetImageData
Accessory:0
Parameter:INTEGER＝5512；INTEGER＝985；INTEGER＝512；INTEGER＝512；INTEGER＝665；INTEGER＝-2048；INTEGER＝1；INTEGER＝500；INTEGER＝100；
CubeContainSize985
PixelSize x：512，y：512，z：665
WindoWWidth：500，WindoWCenter：100
任务处理进程接收到打开数据体命令后，将数据加载到内存中，首先将数据体的基本信息填写到LChildReturnData信息结构中，通知数据通道将内容返回给客户端。如数据体的X、Y、Z的像素大小，默认窗宽窗位值等。
获取基本数据信息后客户端会向数据通道重复发出读数据请求：
<--SEND MESSAGE HEADER(FM_GET_FILE，FMMC_CONNECT)
<--SEND FILE PARAMETER
Command:comGetImageData
Accessory:0
因为三维重建数据体一般都比较大，加载数据是需要一定时间的，所以服务器在加载过程中应该通过数据通道实时向客户端返回加载进度：
->RECEIVE MESSAGE HEADER(FM_GET_FILE_RESPONSE，FMMC_ACCEPT)
-->RECEIVE FILE PARAMETER
Command:comGetImageData
Accessory:0
Parameter:INTEGER＝5500；FLOAT＝10.000000；
Progress:10％
当数据加载完成后数据通道将计算后生成的图像传送到客户端：
-->RECEIVE MESSAGE HEADER(FM_GET_FILE_RESPONSE，FMMC_ACCEPT)
->RECEIVE FILE PARAMETER
Command:comGetImageData
Accessory:273016
Parameter:INTEGER＝5515；INTEGER＝0；SIZE＝532|708；INTEGER＝0；
-->RECEIVE FILE DATA
数据传输时间(毫秒)：0，大小(字节)：273016
数据解码时间(毫秒)：93，大小(字节)：1129968
RGBImage X：532，Y：708，Size：273016
数据加载到客户端后，客户端会根据当前显示布局显示出来，三维数据的加载过程结束。如图11和图12所示为服务端加载实例，图13为客户端的加载实例。
如果一定时间客户端未向服务器发出任务请求，服务端会定时向客户端返回一个空消息，通过这种方法客户端和服务端就可以通过一定的心跳模式来知道之间的存在。避免客户端异常退出后，服务器资源一直被占用的情况的发生：
<--SEND MESSAGE HEADER(FM_GET_FILE，FMMC_CONNECT)
<--SEND FILE PARAMETER
Command:comGetImageData
Accessory:0
-->RECEIVE MESSAGE HEADER(FM_GET_FILE_RESPONSE，FMMC_ACCEPT)
-->RECEIVE FILE PARAMETER
Command:comGetImageData
Accessory:0
Parameter:STRING＝comReturnObjectEvent；
当用户需要三维体进行旋转的时候，客户端会将X，Y，Z值通过命令通道提交到服务器。
-->RECEIVE MESSAGE HEADER(FM_EXECUTE_RESPONSE，FMMC_SUCCESS)
<--SEND MESSAGE HEADER(FM_EXECUTE，FMMC_CONNECT)
<--SEND FILE PARAMETER
Command:4100
Accessory:0
Parameter:INTEGER＝0；INTEGER＝250；INTEGER＝329；INTEGER＝0；
服务端接收到参数发生变化后会将应该的结果计算出来通过数据通过返回给客户端，如图14所示：
-->RECEIVE MESSAGE HEADER
(FM_GET_FILE_SERIES_RESPONSE，FMMC_ACCEPT)
-->RECEIVE FILE PARAMETER
Command:5120
Accessory:290688
Parameter:INTEGER＝5515；INTEGER＝0；SIZE＝822|842；INTEGER＝0；
-->RECEIVE FILE DATA
数据传输时间(毫秒)：0，大小(字节)：290688
数据解码时间(毫秒)：109，大小(字节)：2076372
RGBImage X：822，Y：842，Size：290688
当客户端结束处理后命令通道会向管理进程发出释放请求WM_PROCESS_CLOSE消息，由于三维任务处理进程的处理逻辑非常复杂，管理进程接收到消息后为了保证系统的稳定工作将关闭当前任务处理进程。关闭任务处理进程后为了可以接收其它客户端的处理任务，管理进程将重启一个新的进程来代替旧任务处理进程。当客户端发生错误异常退出，服务端无法接收到关闭处理命令的通知，管理进程通过检测ExecuteTime的刷新时候，如果发现超过一定时候没有变化就可以知道客户端已经端开，直接将对应处理进程关闭。
本领域技术人员不脱离本发明的实质和精神，可以有多种变形方案实现本发明，以上所述仅为本发明较佳可行的实施例而已，并非因此局限本发明的权利范围，凡运用本发明说明书及附图内容所作的等效结构变化，均包含于本发明的权利范围之内。
Claims (10)
1.一种三维图像服务器多任务管理调度方法，其特征在于，包括步骤：
A1、三维图像服务器与至少一个客户端通过私有通信协议分别建立命令通道连接和数据通道连接，所述私有通信协议为TCP/IP协议的应用层协议3DAP；
A2、在所述三维图像服务器中建立相应的命令通道处理进程、数据通道处理进程和任务处理进程，并开辟进程间通信共享内存区；
A3、所述命令通道处理进程与所述客户端传递交互命令和操作参数；
A4、所述任务处理进程根据所述操作参数进行图像三维重建并生成三维图像数据；
A5、所述数据通道处理进程向所述客户端发送所述三维图像数据。
2.根据权利要求1所述的三维图像服务器多任务管理调度方法，其特征在于：所述步骤A2包括步骤：建立管理进程，由所述管理进程开辟所述进程间通信共享内存区。
3.根据权利要求2所述的三维图像服务器多任务管理调度方法，其特征在于：所述步骤A2包括步骤：所述管理进程为所述命令通道处理进程、所述数据通道处理进程和所述任务处理进程在所述进程间通信共享内存区内分配内存资源。
4.根据权利要求3所述的三维图像服务器多任务管理调度方法，其特征在于：所述步骤A2包括步骤：所述管理进程在所述进程间通信共享内存区内设置进程状态表，所述进程状态表用于标记进程的状态。
5.根据权利要求4所述的三维图像服务器多任务管理调度方法，其特征在于：所述步骤A2包括步骤：所述管理进程在所述进程间通信共享内存区内设置进程消息表，所述进程消息表用于存储进程间进行通信的消息内容。
6.根据权利要求5所述的三维图像服务器多任务管理调度方法，其特征在于：所述步骤A2包括步骤：所述管理进程在所述进程间通信共享内存区内设置子进程属性信息结构，所述子进程属性信息结构用于标记进程的相关信息。
7.根据权利要求6所述的三维图像服务器多任务管理调度方法，其特征在于：所述步骤A2包括步骤：所述管理进程在所述进程间通信共享内存区内设置命令通道信息结构。
8.根据权利要求7所述的三维图像服务器多任务管理调度方法，其特征在于：所述步骤A2包括步骤：所述管理进程在所述进程间通信共享内存区内设置数据通道信息结构。
9.根据权利要求8所述的三维图像服务器多任务管理调度方法，其特征在于：所述步骤A2包括步骤：所述管理进程在所述进程间通信共享内存区内设置管理进程属性信息结构。
10.根据权利要求9所述的三维图像服务器多任务管理调度方法，其特征在于：所述管理进程预先启动至少一个命令通道处理进程、至少一个数据通道处理进程和至少一个任务处理进程。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 200910239520 CN101777012B (zh) | 2009-12-31 | 2009-12-31 | 一种三维图像服务器多任务管理调度方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 200910239520 CN101777012B (zh) | 2009-12-31 | 2009-12-31 | 一种三维图像服务器多任务管理调度方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101777012A CN101777012A (zh) | 2010-07-14 |
| CN101777012B true CN101777012B (zh) | 2013-05-08 |
Family
ID=42513481
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN 200910239520 Active CN101777012B (zh) | 2009-12-31 | 2009-12-31 | 一种三维图像服务器多任务管理调度方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101777012B (zh) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101916331B (zh) * | 2010-08-06 | 2013-05-08 | 深圳市蓝韵网络有限公司 | 一种三维服务器数据预处理调度方法 |
| CN101917449B (zh) * | 2010-09-01 | 2013-04-17 | 中国地质大学（武汉） | 一种面向三维空间数据传输的应用层通信方法 |
| CN102073537A (zh) * | 2010-09-29 | 2011-05-25 | 深圳市蓝韵实业有限公司 | 一种高并发Web医学影像服务器的实现方法 |
| CN102592310A (zh) * | 2011-12-28 | 2012-07-18 | 中国人民解放军第四军医大学唐都医院 | 一种用于医学影像教学的移动终端影像三维重建方法 |
| CN103516663B (zh) * | 2012-06-15 | 2016-06-22 | 中国科学院电子学研究所 | 机载合成孔径雷达数据集群式处理方法 |
| CN103886167B (zh) * | 2012-11-15 | 2018-10-09 | 上海联影医疗科技有限公司 | 医学图像处理方法及系统、客户端及服务器 |
| CN104410687B (zh) * | 2014-11-26 | 2018-01-19 | 上海爱数信息技术股份有限公司 | 一种基于管道的多组进程间数据传递方法 |
| CN104852931B (zh) * | 2015-06-12 | 2019-02-01 | 北京京东尚科信息技术有限公司 | 一种通信方法和装置 |
| CN106725562A (zh) * | 2015-11-20 | 2017-05-31 | 上海西门子医疗器械有限公司 | 计算机断层扫描设备、计算单元和计算机断层扫描系统 |
| CN106648932A (zh) * | 2016-12-19 | 2017-05-10 | 四川长虹电器股份有限公司 | 基于Python扩展模块的多进程共享系统及方法 |
| CN106777999A (zh) | 2016-12-26 | 2017-05-31 | 上海联影医疗科技有限公司 | 图像处理方法、系统和装置 |
| CN106790706B (zh) * | 2017-02-27 | 2019-11-19 | 深圳先进技术研究院 | 一种数据资源优化的方法、平台及系统 |
| CN110928701A (zh) * | 2018-09-20 | 2020-03-27 | 北京君正集成电路股份有限公司 | 通讯注册方法和装置 |
| CN110083463B (zh) * | 2019-04-22 | 2021-07-20 | 中国地质大学（北京） | 一种3d图像引擎与数值处理软件间实时数据通信方法 |
| CN112330707A (zh) * | 2020-11-17 | 2021-02-05 | 武汉联影医疗科技有限公司 | 图像处理方法、装置、计算机设备和存储介质 |
| CN115794443B (zh) * | 2023-01-29 | 2023-05-23 | 北京万里红科技有限公司 | 基于共享内存的多进程间通信的方法及装置 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6789147B1 (en) * | 2001-07-24 | 2004-09-07 | Cavium Networks | Interface for a security coprocessor |
| CN1758286A (zh) * | 2005-11-16 | 2006-04-12 | 华中科技大学 | 基于图像的三维远程可视化方法 |
| US7289500B1 (en) * | 2003-07-17 | 2007-10-30 | Novell, Inc. | Method and system for reliable multicast data transmission |
| CN101442534A (zh) * | 2008-12-29 | 2009-05-27 | 上海全景数字技术有限公司 | 传输任务调度方法和系统 |
| CN101478449A (zh) * | 2009-01-22 | 2009-07-08 | 凌阳科技股份有限公司 | 一种协议自动测试方法及其系统 |
-
2009
- 2009-12-31 CN CN 200910239520 patent/CN101777012B/zh active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6789147B1 (en) * | 2001-07-24 | 2004-09-07 | Cavium Networks | Interface for a security coprocessor |
| US7289500B1 (en) * | 2003-07-17 | 2007-10-30 | Novell, Inc. | Method and system for reliable multicast data transmission |
| CN1758286A (zh) * | 2005-11-16 | 2006-04-12 | 华中科技大学 | 基于图像的三维远程可视化方法 |
| CN101442534A (zh) * | 2008-12-29 | 2009-05-27 | 上海全景数字技术有限公司 | 传输任务调度方法和系统 |
| CN101478449A (zh) * | 2009-01-22 | 2009-07-08 | 凌阳科技股份有限公司 | 一种协议自动测试方法及其系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101777012A (zh) | 2010-07-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101777012B (zh) | 一种三维图像服务器多任务管理调度方法 | |
| US11129583B2 (en) | Apparatus and system for rule based visualization of digital breast tomosynthesis and other volumetric images | |
| US10818048B2 (en) | Advanced medical image processing wizard | |
| CN100452067C (zh) | 一种医学图像数据传输与三维可视化的实现方法 | |
| US8793301B2 (en) | Method and system for dynamic image processing | |
| US20190313909A1 (en) | Dependency-based startup in a multi-modality medical system | |
| US9984206B2 (en) | System and method for medical resource scheduling in a distributed medical system | |
| Erdman et al. | Grand challenge: Applying regulatory science and big data to improve medical device innovation | |
| CN109215764B (zh) | 一种医学图像四维可视化的方法及装置 | |
| CN111223554A (zh) | 一种智能ai pacs系统及其检查报告信息处理方法 | |
| CN103455703B (zh) | 计算机系统、医用图像诊断装置以及图像显示方法 | |
| US20140087342A1 (en) | Training and testing system for advanced image processing | |
| CN105306573B (zh) | 医学影像原始数据调度方法和医学影像传输系统 | |
| CN103365950A (zh) | 用于加载医学图像数据的方法以及用于执行该方法的装置 | |
| CN204595857U (zh) | 一种远程会诊系统 | |
| Zhang | Web-based medical data visualization and information sharing towards application in distributed diagnosis | |
| CN101778100B (zh) | 一种三维图像服务器与客户端通信的实现方法 | |
| JP2008047157A (ja) | 医療情報管理支援装置 | |
| CN101266634A (zh) | 用于医学设备之间的数据交换的方法 | |
| EP2332124B1 (en) | Patient specific anatomical sketches for medical reports | |
| JP2009069977A (ja) | 医用レポート作成システム及び医用レポート作成装置並びに医用レポート作成方法 | |
| JP2007299064A (ja) | 医療情報管理支援装置 | |
| AU2016299367B2 (en) | Apparatus and method for visualizing Digital Breast Tomosynthesis and anonymized display data export | |
| JPWO2019198128A1 (ja) | 内視鏡業務支援システムおよび内視鏡業務支援方法 | |
| JPH0784922A (ja) | 情報伝達システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| ASS | Succession or assignment of patent right |
Owner name: SHENZHEN LANYUN NETWORK CO., LTD. Free format text: FORMER OWNER: LANYUN INDUSTRY CO., LTD.;SHENZHEN CITY Effective date: 20120820 |
|
| C41 | Transfer of patent application or patent right or utility model | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20120820 Address after: Futian District King Road Shenzhen city Guangdong province 518034 green garden building room 410 (only office) Applicant after: Shenzhen Landwind Network Co., Ltd. Address before: 518034 Guangdong city of Shenzhen province Futian District King Road Green Garden E room 408-413 Applicant before: Landwind Co., Ltd. |
|
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| C56 | Change in the name or address of the patentee |
Owner name: LANWANG TECHNOLOGY CO., LTD. Free format text: FORMER NAME: SHENZHEN LANDWIND NETWORK CO., LTD. |
|
| CP03 | Change of name, title or address |
Address after: Nanshan District Xueyuan Road in Shenzhen city of Guangdong province 518000 No. 1001 Nanshan Chi Park A3 building 6 floor Patentee after: LANWON SCIENCE & TECHNOLOGY CO., LTD. Address before: Futian District King Road Shenzhen city Guangdong province 518034 green garden building room 410 (only office) Patentee before: Shenzhen Landwind Network Co., Ltd. |
|
| C56 | Change in the name or address of the patentee | ||
| CP01 | Change in the name or title of a patent holder |
Address after: Nanshan District Xueyuan Road in Shenzhen city of Guangdong province 518000 No. 1001 Nanshan Chi Park A3 building 6 floor Patentee after: LANWON TECHNOLOGY CO., LTD. Address before: Nanshan District Xueyuan Road in Shenzhen city of Guangdong province 518000 No. 1001 Nanshan Chi Park A3 building 6 floor Patentee before: LANWON SCIENCE & TECHNOLOGY CO., LTD. |