CN101783794A - 一种改善存储服务器通信服务稳定性的方法 - Google Patents
一种改善存储服务器通信服务稳定性的方法 Download PDFInfo
- Publication number
- CN101783794A CN101783794A CN200910188557A CN200910188557A CN101783794A CN 101783794 A CN101783794 A CN 101783794A CN 200910188557 A CN200910188557 A CN 200910188557A CN 200910188557 A CN200910188557 A CN 200910188557A CN 101783794 A CN101783794 A CN 101783794A
- Authority
- CN
- China
- Prior art keywords
- communication service
- subprocess
- storage server
- host process
- described communication
- 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.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种改善存储服务器通信服务稳定性的方法,包括步骤:A1、在存储服务器上建立通信服务主进程;A2、所述通信服务主进程启动至少一个通信服务子进程,并开辟进程间通信共享内存区;A3、所述通信服务主进程指定一个所述通信服务子进程进入监听状态,并与客户端进行通信。本发明改善存储服务器通信服务稳定性的方法在存储服务器上采用通信服务主进程和通信服务子进程为客户端提供通信服务,消除了线程通信服务不稳定的因素,极大改善了存储服务器的通信服务稳定性,本发明改善存储服务器通信服务稳定性的方法是PACS系统通信技术的重大进步。
Description
技术领域
本发明涉及通信技术领域,具体涉及一种改善存储服务器通信服务稳定性的方法。
背景技术
PACS(Picture Arching and Communication System)是近年来随着数字成像技术、计算机技术和网络技术的进步而迅速发展起来的、旨在全面解决医学图像的获取、显示、存储、传送和管理的综合系统。由于有先进的图像处理技术和通信技术作为支持手段,PACS系统可以极大地提高医院目前的事务处理能力,提高了工作效率,节约了成本,克服了手工管理胶片的缺点。完整的PACS系统可分为医学图像获取、大容量数据存储、图像显示和处理、数据库管理以及用传输影像的局域网或广域网等五个单元。其中,医学图像获取及影像传输是PACS的重要组成部分,是影像设备与存储服务器、存储服务器与阅片端连接的通道。存储服务器用于提供与设备连接与及阅片端连接的通信服务的稳定性直接影响到整个系统的性能。一般通信的底层使用TCP/IP协议实现,基与底层通信协议之上的是DICOM上层应用协议。
DICOM(Digital Imaging and Communication in Medicine)是医疗设备的国际标准通信协议。现在广泛使用的标准是DICOM3.0,DICOM3.0标准的制定使得医学图像及各种数字信息在计算机间的传送有了一个统一的标准。目前,国内外的医疗设备厂商一般都以许可证方式提供符合DICOM标准的医疗设备,以解决不同厂商的设备互连问题。DICOM3.0同时也是通用PACS系统接收设备数据所遵循的标准协议。上层协议(Upper Layer Protocol)是DICOM为了实现自身功能而对TCP/IP协议进行扩充性定义的应用层协议。DICOM标准《PS3.8:支持消息交换的网络通信》给出了上层协议状态机的定义以及上层协议PDU的格式等。上层协议为消息交换层提供上层服务,上层服务等同于基于ISO/OSI协议定义的关联控制服务元素ACSE提供的关联管理服务和数据传输服务。
如图1所示,DICOM标准中存储SCU(Service Class User)和存储SCP(Service Class Provider)分别对应Client/Server模型中的存储客户端和存储服务器。
存储SCU和存储SCP之间的图像传输可以分为五个步骤:
第一步:建立关联,即建立底层的通信管道。按照前面描述的规则和要求,SCU使用上层服务,发送关联建立请求A-ASSOCIATE-RQ到SCP,SCP接受该请求,然后SCU和SCP协商它们各自支持的存储SOP类以及传输图像的编码规则——传输语法,SCP把协商的结果封装于关联建立接受/拒绝A-ASSOCIATE-AC/RJ响应中。如果协商成功,即SCU收到A-ASSOCIATE-AC,则表示SCU和SCP之间的关联建立成功。
第二步:图像编码,即SCU发送图像前的准备工作。SCU遵循双方协商后的传输语法,对要传送的图像进行编码,编码的结构为数据流,封装于完成C-STORE服务的C-STORE-RQ请求中。
第三步:发送/接受存储请求/响应C-STORE-RQ/RP。SCU使用底层的DIMSE服务,把封装了图像的C-STORE-RQ请求发送到SCP,并等待来自SCP的存储响应C-STORE-RP。SCP接受来自SCU的存储请求,经过图像解码处理,把图像存储于某一媒体上,并发送包含此次存储操作状态码的存储响应到SCU。SCU根据收到的存储操作的状态码,进行相应的处理。
第四步:图像解码,即对应于SCU的准备工作——图像编码,SCP按照传输语法进行的图像后处理。把存储请求中的图像从数据流形式转变为文件形式或者数据库的大二进制字段进行存储。
第五步:释放关联,通信完成后,双方通过发送关联释放请求/响应A-RELEASE-RQ/RP来释放此次连接。至此,此次存储操作完成。
存储服务器必须同时处理多台客户端发过来的请求任务,为了实现多任务并行处理方法,现有技术存储服务器通信服务的实现方法是启动一个主线程用于实时监听客户端发过来的请求,当接收到一个请求后主线程会新启动一个子线程负责处理该客户端的请求任务,然后主线程继续监听请求。子线程完成客户端的处理任务后将结果还回给客户端然后断开连接,子线程结束任务销毁线程占用资源。使用这种方法可以满足并行处理的要求,但是虽然线程间任务是相互独立的,可使用的资源是共用的,他们之间有可能相互影响。当多个任务同时进行过程中,有一个任务处理发生错误无法执行下去的时候有可能会影响到其它任务的执行,由于各种错误的累积必然会出现一些不可预知的情况的发生,最后可能导致存储服务器整个通信服务程序崩溃。
发明内容
本发明要解决的技术问题是提供一种改善存储服务器通信服务稳定性的方法,克服现有技术存储服务器通信服务单纯采用子线程与每个客户端进行通信,容易导致通信服务不稳定的缺陷。
本发明为解决上述技术问题所采用的技术方案为:
一种改善存储服务器通信服务稳定性的方法,包括步骤:
A1、在存储服务器上建立通信服务主进程;
A2、所述通信服务主进程启动至少一个通信服务子进程,并开辟进程间通信共享内存区;
A3、所述通信服务主进程指定一个所述通信服务子进程进入监听状态,并与客户端进行通信。
所述的改善存储服务器通信服务稳定性的方法,其中所述步骤A2包括步骤:所述通信服务主进程在所述进程间通信共享内存区内设置进程状态表,所述进程状态表用于标记所述通信服务主进程和所述通信服务子进程的状态。
所述的改善存储服务器通信服务稳定性的方法,其中所述步骤A2包括步骤:所述通信服务主进程在所述进程间通信共享内存区内设置进程消息表,所述进程消息表用于存储进程间进行通信的消息内容。
所述的改善存储服务器通信服务稳定性的方法,其中所述步骤A2包括步骤:所述通信服务主进程在所述进程间通信共享内存区内设置通信服务子进程属性信息结构,所述通信服务子进程属性信息结构用于记录所述通信服务子进程的相关信息。
所述的改善存储服务器通信服务稳定性的方法,其中所述步骤A2包括步骤:所述通信服务主进程在所述进程间通信共享内存区内设置通信服务主进程属性信息结构,所述通信服务主进程属性信息结构用于记录所述通信服务主进程的相关信息。
所述的改善存储服务器通信服务稳定性的方法,其中所述步骤A3包括步骤:进入监听状态的所述通信服务子进程与所述客户端通信结束后进入挂起状态。
所述的改善存储服务器通信服务稳定性的方法,其中为每个所述通信服务子进程设置生存期,超过生存期的所述通信服务子进程结束运行。
所述的改善存储服务器通信服务稳定性的方法,其中所述通信服务主进程设置初始默认启动子进程数,如果处于生存状态的所述通信服务子进程数量小于所述初始默认启动子进程数,所述通信服务主进程启动新的所述通信服务子进程。
本发明的有益效果:本发明改善存储服务器通信服务稳定性的方法在存储服务器上采用通信服务主进程和通信服务子进程为客户端提供通信服务,消除了线程通信服务不稳定的因素,极大改善了存储服务器的通信服务稳定性,本发明改善存储服务器通信服务稳定性的方法是PACS系统通信技术的重大进步。
附图说明
本发明包括如下附图:
图1为现有技术DICOM标准中图像传输过程流程图;
图2为本发明改善存储服务器通信服务稳定性的方法流程图;
图3为本发明存储服务器与医疗影像设备之间数据传输示意图;
图4为本发明改善存储服务器通信服务稳定性的方法实施例流程图;
图5为本发明由任务管理器查看到的通信服务子进程示意图;
图6为本发明进程状态示意图。
具体实施方式
下面根据附图和实施例对本发明作进一步详细说明:
如图2所示,首先在存储服务器上建立通信服务主进程;通信服务主进程启动至少一个通信服务子进程,并开辟进程间通信共享内存区;通信服务主进程指定一个通信服务子进程进入监听状态,并与客户端进行通信。每个进程具有独立的数据空间,要进行数据传递需要分配一个共享内存区。通信服务主进程通过系统函数CreateFileMapping创建一个进程间通信共享内存区,通过MapViewOfFile将内存区映射到进程地址中,然后建立两个数据结构:通信服务子进程属性信息结构和通信服务主进程属性信息结构,将两个结构映射到进程间通信共享内存区中:
通信服务子进程属性信息结构:
struct LChildProcInfo
{
LProcState State;//进程当前状态
HANDLE ProcessHandle;//进程句柄
int ProcessId;//进程编号
HWND Handle;//进程接收消息句柄
DATE OpenTime;//进程打开时间
DATE SuspendTime;//进程最后一次挂起时间
};
通信服务主进程属性信息结构:
struct LParentProcInfo
{
HWND Handle;//主进程消息句柄
LChildProcInfo Child[200];//子进程信息列表
};
通信服务主进程在进程间通信共享内存区中设置进程状态表和进程消息表,分别记录管理主进程及任务子进程的状态和通信消息内容,这样进程间就可以知道各自的状态,以便如何进行下一步的操作。进程状态表如表1所示:
表1
进程消息表如表2所示:
表2
消息命令 | 命令描述 |
WM_PROCESS_OPEN | 进程已经打开,向父进程发出通知 |
WM_PROCESS_CLOSE | 进程已经关闭,向父进程发出通知 |
WM_PROCESS_EXECUTE | 向父进程发出通知,进程已经开始执行操作,需要重新启动一个新进程进行监听 |
WM_PROCESS_SUSPEND | 向父进程发出通知,进程已经挂起 |
WM_PROCESS_LISTEN | 向子进程发出通知,要求进程进行监听 |
WM_PROCESS_Stop | 向子进程发出通知,要求停止监听 |
通信服务主进程启动后将进程消息句柄记录在通信服务主进程属性信息结构中。为了避免启动通信服务子进程影响系统的运行效率,通信服务主进程预先启动几个任务子进程,使用CreateProcess启动通信服务子进程,函数调用结束后返回进程ID号,找出进程状态表中未记录进程信息的位置,将内容写入该位置,同时将通信服务子进程设置为psInit状态表示通信服务子进程正在启动中,还不能接收任务处理。通信服务子进程启动后通过系统函数OpenFileMapping打开通信服务主进程创建的共享内存区,通过MapViewOfFile将内存区影射到该通信服务子进程的进程地址中,这样通信服务子进程就可以访问进程状态表和进程消息表。使用GetCurrendProcessId获取该进程ID找出进程状态表中记录该该通信服务子进程的位置,将该通信服务子进程状态修改为psSuspend,说明该通信服务子进程已经启动成功,可以执行任务。同时使用PostMessage向通信服务主进程发出WM_PROCESS_OPEN消息,通知通信服务主进程可以为该通信服务子进程分配任务。通信服务主进程接收到通信服务子进程启动成功的消息后,选择一个通信服务子进程做为监听进程,向该子进程发出WM_PROCESS_LISTEN消息,该子进程接收到消息后进入监听状态,状态信息被设置为psListen。当通信服务子进程接收到一个存储客户端的任务处理请求后进入执行状态psExecute(执行过程图1所示),关闭进程监听,向通信服务主进程发出WM_PROCESS_EXECUTE消息。通信服务主进程接收到通信服务子进程发过来的WM_PROCESS_EXECUTE消息后,在进程状态表中找出标识为psSuspend状态的进程,向该进程发出WM_PROCESS_LISTEN消息,要求该进程进入监听状态。如果所有的进程都处于psExecute状态,通信服务主进程将启动一个新通信服务子进程,直接将其设置为psListen状态。新通信服务子进程启动后发现自身进程状态为psListen,直接进入监听状态。通信服务子进程进入psSuspend状态后,会将挂起时间记录在通信服务子进程属性信息的变量SuspendTime中,通信服务主进程为每个通信服务子进程设置了一个生存期,然后通过与SuspendTime时间进行比较来判断是否已经超过了进程的生存期。如果通信服务子进程已经超过生存期结束该通信服务子进程。由于每个通信服务子进程都有一定的生存期,也就是说过一段时间后所有的旧通信服务子进程都会被关闭,如果没有了通信服务子进程,就无法接收客户端的请求,所以通信服务主进程设置了一个初始默认启动进程数,如果通信服务子进程数量小于初始默认启动进程数,通信服务主进程会启动新的通信服务子进程来补充处理任务。
具体实施例
如图3所示,在医学影像应用中,影像流是建立在数据的传输基础上,为实现数据的传输我们在TCP/IP通信层之上实现了DICOM Store应用层协议。因为医学影响数据的重要性,要求PACS图像存储服务器必须长期稳定的工作,与之连接的多台影像设备必须保持正常,随时响应设备的消息。在存储服务器上开发了两个应用程序,分别是DCMStoreServer.exe和DCMStoreChild.exe,前一个程序负责管理任务,后者负责实现DICOM Store协议定义的所有任务,包括监听设备的连接请求,影像数据的接收工作等。DCMStoreServer和DCMStoreChild实例化后的具体运行流程如图4所示:
DCMStoreServer.exe管理主进程启动后将进程消息句柄记录在属性信息中。为了避免启动任务子进程影响系统接收图像的运行效率,在启动管理主进程后应该预先启动几个DCMStoreChild.exe任务子进程,使用CreateProcess启动任务子进程,函数调用结束后返回进程ID号,找出进程状态表中未记录进程信息的位置,将内容写入该位置,同时将进程设置为psInit状态表示该任务子进程正在启动中,还不能接收任务处理。
DCMStoreChild.exe进程启动后通过打开管理主进程创建的共享内存区,将其影射到该进程地址中,这样任务子进程就可以访问进程信息列表中的信息。将进程状态修改为psSuspend,说明进程已经启动成功,可以执行任务。同时使用PostMessage向DCMStoreServer.exe进程发出WM_PROCESS_OPEN消息,通知管理主进程可以为该进程分配任务。
DCMStoreServer.exe管理主进程接收到任务子进程启动成功的消息后,选择一个DCMStoreChild.exe任务子进程作为监听进程,向该任务子进程发出WM_PROCESS_LISTEN消息,该任务子进程接收到消息后进入监听状态,负责实时监听设备发过来的DICOM Store连接请求,状态信息被设置为psListen。当DCMStoreChild.exe进程接收到一个设备端的DICOM Store发送任务处理请求后该进程进入执行状态psExecute,开始接收设备发过来的影像数据并进行归档。同时关闭进程监听状态,向管理主进程发出WM_PROCESS_EXECUTE消息。DCMStoreServer.exe进程接收到子进程发过来的WM_PROCESS_EXECUTE消息后,在进程列表中找出标识为psSuspend状态的进程,向该进程发出WM_PROCESS_LISTEN消息,要求该进程进入监听状态。如果所有的进程都处于psExecute状态,管理主进程将启动一个任务子进程,直接将其设置为psListen状态。新DCMStoreChild.exe进程启动后发现该进程状态为psListen,直接进入监听状态。DCMStoreChild.exe进程进入psSuspend状态后会将挂起时间记录在信息列表结构变量SuspendTime中,然后管理主进程为每个任务子进程设置了一个生存期,通过与SuspendTime时间进行比较来判断是否已经超过了任务子进程的生存期。如果任务子进程已经超过生存期结束进程。由于每个DCMStoreChild.exe任务子进程都有一定的生存期,也就是说过一段时间后所有的任务子进程都会被关闭,如果没有了任务子进程,就无法接收客户端的请求,所以管理主进程设置了一个初始默认启动进程数,如果任务子进程的数量小于初始默认启动进程数,DCMStoreServer.exe进程会启动新的任务子进程来补充处理任务。
图5所示是应用程序实例后在任务管理器的表现方式。在管理主进程中可以了解到各任务子进程的使用情况如图6所示。DCMStoreServer.exe管理主进程负责各个任务子进程的调度,其本身的功能相对简单,管理主进程使用的技术都是最基本的系统功能,可以保证其长期稳定的工作。所有的业务逻辑,和复杂的技术都放到了DCMStoreChild.exe任务子进程来实现,当任务子进程处理过程中出现不可预知的错误,导致程序中止也只会影响到当前的一次操作流程,并不会影响到整个系统的运行。
本领域技术人员不脱离本发明的实质和精神,可以有多种变形方案实现本发明,以上所述仅为本发明较佳可行的实施例而已,并非因此局限本发明的权利范围,凡运用本发明说明书及附图内容所作的等效结构变化,均包含于本发明的权利范围之内。
Claims (8)
1.一种改善存储服务器通信服务稳定性的方法,其特征在于,包括步骤:
A1、在存储服务器上建立通信服务主进程;
A2、所述通信服务主进程启动至少一个通信服务子进程,并开辟进程间通信共享内存区;
A3、所述通信服务主进程指定一个所述通信服务子进程进入监听状态,并与客户端进行通信。
2.根据权利要求1所述的改善存储服务器通信服务稳定性的方法,其特征在于,所述步骤A2包括步骤:所述通信服务主进程在所述进程间通信共享内存区内设置进程状态表,所述进程状态表用于标记所述通信服务主进程和所述通信服务子进程的状态。
3.根据权利要求2所述的改善存储服务器通信服务稳定性的方法,其特征在于,所述步骤A2包括步骤:所述通信服务主进程在所述进程间通信共享内存区内设置进程消息表,所述进程消息表用于存储进程间进行通信的消息内容。
4.根据权利要求3所述的改善Web服务器通信服务稳定性的方法,其特征在于,所述步骤A2包括步骤:所述通信服务主进程在所述进程间通信共享内存区内设置通信服务子进程属性信息结构,所述通信服务子进程属性信息结构用于记录所述通信服务子进程的相关信息。
5.根据权利要求4所述的改善Web服务器通信服务稳定性的方法,其特征在于,所述步骤A2包括步骤:所述通信服务主进程在所述进程间通信共享内存区内设置通信服务主进程属性信息结构,所述通信服务主进程属性信息结构用于记录所述通信服务主进程的相关信息。
6.根据权利要求5所述的改善存储服务器通信服务稳定性的方法,其特征在于,所述步骤A3包括步骤:进入监听状态的所述通信服务子进程与所述客户端通信结束后进入挂起状态。
7.根据权利要求6所述的改善存储服务器通信服务稳定性的方法,其特征在于:为每个所述通信服务子进程设置生存期,超过生存期的所述通信服务子进程结束运行。
8.根据权利要求7所述的改善存储服务器通信服务稳定性的方法,其特征在于:所述通信服务主进程设置初始默认启动子进程数,如果处于生存状态的所述通信服务子进程数量小于所述初始默认启动子进程数,所述通信服务主进程启动新的所述通信服务子进程。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200910188557A CN101783794A (zh) | 2009-12-01 | 2009-12-01 | 一种改善存储服务器通信服务稳定性的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200910188557A CN101783794A (zh) | 2009-12-01 | 2009-12-01 | 一种改善存储服务器通信服务稳定性的方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101783794A true CN101783794A (zh) | 2010-07-21 |
Family
ID=42523613
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN200910188557A Pending CN101783794A (zh) | 2009-12-01 | 2009-12-01 | 一种改善存储服务器通信服务稳定性的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101783794A (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103176854A (zh) * | 2011-12-26 | 2013-06-26 | 腾讯科技(深圳)有限公司 | 一种进程间通信方法、装置及系统 |
CN103631664A (zh) * | 2013-12-09 | 2014-03-12 | 北京奇虎科技有限公司 | 一种进程间的通信方法和装置 |
CN105451028A (zh) * | 2015-12-03 | 2016-03-30 | 深圳市泛海三江电子有限公司 | 存储服务器及其实现方法 |
CN107181794A (zh) * | 2017-04-27 | 2017-09-19 | 广州慧扬健康科技有限公司 | 基于dimse消息发送与接收的dicom网络传输系统 |
CN107870816A (zh) * | 2016-09-27 | 2018-04-03 | 苏宁云商集团股份有限公司 | 一种用于图像处理和存储的方法及装置 |
-
2009
- 2009-12-01 CN CN200910188557A patent/CN101783794A/zh active Pending
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103176854A (zh) * | 2011-12-26 | 2013-06-26 | 腾讯科技(深圳)有限公司 | 一种进程间通信方法、装置及系统 |
CN103176854B (zh) * | 2011-12-26 | 2018-09-07 | 腾讯科技(深圳)有限公司 | 一种进程间通信方法、装置及系统 |
CN103631664A (zh) * | 2013-12-09 | 2014-03-12 | 北京奇虎科技有限公司 | 一种进程间的通信方法和装置 |
CN103631664B (zh) * | 2013-12-09 | 2016-09-28 | 北京奇虎科技有限公司 | 一种进程间的通信方法和装置 |
CN105451028A (zh) * | 2015-12-03 | 2016-03-30 | 深圳市泛海三江电子有限公司 | 存储服务器及其实现方法 |
CN105451028B (zh) * | 2015-12-03 | 2019-04-02 | 深圳市泛海三江电子股份有限公司 | 存储服务器及其实现方法 |
CN107870816A (zh) * | 2016-09-27 | 2018-04-03 | 苏宁云商集团股份有限公司 | 一种用于图像处理和存储的方法及装置 |
CN107870816B (zh) * | 2016-09-27 | 2021-11-26 | 苏宁易购集团股份有限公司 | 一种用于图像处理和存储的方法及装置 |
CN107181794A (zh) * | 2017-04-27 | 2017-09-19 | 广州慧扬健康科技有限公司 | 基于dimse消息发送与接收的dicom网络传输系统 |
CN107181794B (zh) * | 2017-04-27 | 2020-11-17 | 广州慧扬健康科技有限公司 | 基于dimse消息发送与接收的dicom网络传输方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11481244B2 (en) | Methods and systems that verify endpoints and external tasks in release-pipeline prior to execution | |
US8832710B2 (en) | Operation control for deploying and managing software service in a virtual environment | |
US8112526B2 (en) | Process migration based on service availability in a multi-node environment | |
US20100042720A1 (en) | Method and system for intelligently leveraging cloud computing resources | |
CN105357273B (zh) | 异步通信模式下socket通信与进程管理通用平台及方法 | |
EP0794490A2 (en) | Dynamic execution unit management for high performance server system | |
US20050283534A1 (en) | Goal-oriented predictive scheduling in a grid environment | |
CN114666333B (zh) | 一种基于多租户理论面向云计算资源调度问题的控制方法 | |
CN106161537A (zh) | 远程过程调用的处理方法、装置、系统及电子设备 | |
CN104579792A (zh) | 多适配方式实现多种类型虚拟资源集中管理架构及方法 | |
CN104615489B (zh) | 一种多节点数据交互的实现方法 | |
CN101783794A (zh) | 一种改善存储服务器通信服务稳定性的方法 | |
CN103765387A (zh) | 便携式计算装置中的分布式资源管理 | |
CN102196033A (zh) | 远程内容分类以及使用多个传输信道的传输 | |
CN111240806B (zh) | 一种分布式容器镜像构建调度方法 | |
WO2021051881A1 (zh) | Vpp 集群管理方法及装置、计算机设备及存储介质 | |
CN105874433A (zh) | 用于支持分布式数据网格中的异步调用的系统和方法 | |
CN113886089A (zh) | 一种任务处理方法、装置、系统、设备及介质 | |
CN112637304A (zh) | 一种跨云资源处理系统和资源管理方法 | |
CN109446062A (zh) | 云计算服务中的软件调试的方法和装置 | |
KR100370548B1 (ko) | 임베디드 시스템의 통합 소프트웨어 개발 프레임워크를제공하는 실시간 미들웨어 장치 및 그 서비스 방법 | |
US20090319662A1 (en) | Process Migration Based on Exception Handling in a Multi-Node Environment | |
CN113485830A (zh) | 一种电网监控系统微服务自动扩容方法 | |
TW200803282A (en) | Technique for controlling external communication of embedded device using proxy server | |
CN111522630A (zh) | 基于批次调度中心的计划任务执行方法以及系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20100721 |