OpenVOS 운영 체제는 전체적으로 시스템을 프로그래밍할 수 있는 높은 수준의 응용 프로그램 프로그래밍 인터페이스(API)를 제공합니다. 그러나 때로는 너무 쉬워집니다 - 간단한 서브 루틴 전화가 $... 루틴은 복잡성을 많이 숨길 수 있습니다.
이것은 당신이 당신의 응용 프로그램 디자인에서 그들을 피할 수 있도록 이러한 함정에 주의를 호출하는 게시물의 불규칙 한 시리즈의 첫 번째입니다.
25선 메시지의 악
터미널의25번째(또는 하단) 줄에 메시지를 작성하는 기능을 통해 사용자는(또는 실행 중인 프로그램)을 사용하여 다른 사용자에게 비정상적인 조건을 알릴 수 있습니다. 명령줄 인터페이스는 send_message 명령입니다. 명령 및 사용자 프로그램은 궁극적으로 s$send_message API 하위 루틴을 호출합니다. 이 호출에 대한 인수는 수신기의 user_name, 해당 사용자가 로그인할 수 있는 위치에 대한 대상 module_name, 알림 텍스트 및 일부 플래그를 제공하여 작업의 측면을 수정합니다. 권한 있는 호출자는 보낸 사람의 이름을 지정할 수 있습니다. 그렇지 않으면 전송 프로세스의 user_name 기본값입니다.
지금까지는 간단해 보입니다. 이 작업에는 다른 사용자가 소유한 터미널에 액세스해야 하므로 커널은 대상 모듈의 The감독관 프로세스에 대한 서버 큐에서 요청을 보냅니다. 일반적으로 전송 프로세스는 메시지 배달 상태를 기다리지만 이 응답을 기다리지 않도록 선택할 수 있습니다.
모든 모듈에 대한 감독관 프로세스는 모든 로그인 프로세스와 해당 프로세스에서 사용하는 터미널 장치를 추적합니다. 메시지 전송 요청을 받으면 프로세스 및 장치 목록을 검색하고 receiver_name 인수와 일치하는 각 프로세스 user_name 대해 프로세스의 터미널 장치에 포트를 연결하고 포트를 열고 알림을 줄에 메시지를 쓰고 포트를 닫고 포트를 분리합니다. 여러 프로세스가 receiver_name 인수와 일치하는 경우 이 연결/열기/쓰기/닫기/분리 주기는 각각 반복됩니다.
좋아 - 이것은 우리가 처음 이야기보다 조금 더 복잡합니다. 또한 시스템의 특정 모듈은 실제 단말이 Open StrataLink(OSL)를 사용하여 네트워크를 통해 로그인하는 장치인 다른 시스템/모듈의 장치인 로그인 프로세스를 호스팅할 수 있습니다(로그인 –모듈 명령). 이제 해당 터미널의 겉보기에 간단한 연결/열기/쓰기/닫기/분리 작업은 OSL 프로세스및 네트워크 원격 프로시저 호출을 원격 모듈로 호출해야 하며 온 모듈 처리보다 훨씬 비용이 많이 듭니다.
효과의 배율은 수신기 user_name 여러 또는 모든 로그인 사용자와 일치할 수 있는 별이름으로 지정될 때 발생합니다. 그리고 대상 모듈도 별이름으로 지정되면 더욱 확대된다. 최악의 경우 모듈 "*"(현재 시스템의 모든 모듈)에서 사용자 "**"(모든 사용자, 모든 그룹)에게 메시지를 보내는 것입니다.
구현
s$expand_module_starname(target_module) => module_list;
foreach module_name in module_list
send_overseer_request(module_name, send_message_request_data)
The message is sent via a server queue and OSL to TheOverseer process
on that module.
TheOverseer process on each receiving module then does:
foreach terminal_process in TheOverseer’s list of
login processes and sub-processes;
if (terminal_process user_name matches receiver star name)
if (messages_queued_for_device < 5)
queue it for the login device
else
reject the request (e$too_many_terminal_messages)
동시에 한 번에 최대 10개의 포트를 사용하여 큐에 대기된 포트를 보냅니다.
터미널에 메시지;
각 단자마다 각 메시지에 대해
포트 연결
오픈 포트
s$control(... WRITE_SYSTEM_MESSAGE...)
포트 닫기
데타치 포트
이 처리는 각 단말의 no_wait_mode 수행되므로
지연(예: 네트워크 전체의 I/O 요청)은
해당 터미널에 대한 메시지 처리입니다.
메시지를 300초 만에 전달할 수 없는 경우 플러시됩니다.
응용 프로그램이 이 메커니즘을 사용하여 오류를 보고하고 오류가 많이 발생하면 응용 프로그램이 보고에 쉽게 빠져 다른 메시지가 처리되기를 기다리며 너무 빨리 도착하는 메시지로 사용자 터미널을 범람할 수 있습니다.
회피
이제 무대 뒤에서 무슨 일이 일어나고 있는지 알았으니, 제가 줄 수 있는 지침은 다음과 입니다.
- 사용자 이름과 모듈 이름에 대한 스타 이름을 신중하게 만들어 메시지를 가져와야 하는 사용자만 도달하고 다른 사용자에게 도달할 수 있습니다. 예를 들어 John_Doe.* 또는 *. 운영 또는 John_Doe.SysAdmin.
- 각 알림을 별도로 보내고 보낼 사용자의 별 이름 이외의 목록을 구현하는 것이 좋습니다.
- 오류 메시지의 세부 정보(예: 오류 로그)를 배치하고 s$send_message 사용하여 오류의 존재만 경고합니다.
- 알림 빈도를 합리적인 것으로 제한합니다(아마도 분당 한 번 이상).
- 보낸 마지막 메시지와 동일한 메시지를 억제합니다. 새 새 는 이전 오버레이 것입니다.
다른 제안이 있는 경우 다른 제안을 보려면 의견을 게시하십시오.
회사