약 18 개월 전 나는 OpenVOS 릴리스 17.1에서 작동을 받아들이는 방법에 대한 변화에 대해 이야기하는 블로그를 썼습니다. 응용 프로그램 코드가 POSIX 기반인 경우에만 이러한 변경 사항이 적용된다는 것을 나타내지 않았습니다. 요약하려면 17.1 STCP 이전에 서버 응용 프로그램 코드가 수락 루틴을 호출한 경우에만 클라이언트 연결 요청에 회신합니다. 코드가 호출되지 않은 경우 클라이언트의 연결 요청은 큐로 이동하지만 응답되지 않습니다. 응용 프로그램이 수락되면 STCP는 연결 회신을 보냅니다. 클라이언트가 여전히 대기 중이면 해당 시간에 연결이 완료됩니다. 클라이언트가 이미 포기한 경우 재설정된 연결 회신에 응답하고 STCP는 연결을 버리고 수락이 중단(차단 모드로 가정)하고 다른 연결을 기다립니다.
그림 1은 이 시나리오를 보여 주며, 왼쪽 정당화 된 텍스트 줄은 서버 응용 프로그램에서 상태 메시지이며, 들여쓰기 packet_monitor 선 (약간 수정)은 클라이언트 활동의 결과입니다. 응용 프로그램 (acceptTestnoPosix)는 포트 12345에서 시작되고 듣고, 일단 듣기300 초 동안 잠을 간다. 그런 다음 클라이언트는 Syn(S) 플래그 세트로 포트 12345로 TCP 세그먼트를 전송하여 포트 12345에 연결합니다. 포기하기 전에 세 번 시도합니다. 300초 후에 응용 프로그램이 깨어나고 통화가 수락됩니다. STCP 스택은 Syn 및 Ack(SA) 플래그가 설정된 TCP 세그먼트를 사용하여 클라이언트에 회신합니다. 클라이언트에 리셋(R)을 보내는 경우 더 이상 연결 레코드가 없으므로 이 시점에서 STCP블록이 차단됩니다. 소켓이 차단되지 않는 모드허용에 있는 경우 EAGAIN 오류로 반환되었을 것입니다.
수락테스트노포식스 12345 실행 수락테스트노포식스 12345 300초 동안 수면 11:04:45.923 R TCP 164.152.77.50 164.152.77.217 11071 12345 S 11:04:48.925 R TCP 164.152.77.50 164.152.77.217 11071 12345 S 11:04:54.937 R TCP 164.152.77.50 164.152.77.217 11071 12345 S 포트 번호 12345에서 연결을 수락할 준비가 되었습니다. 11:09:41.852 TTCP 164.152.77.217 164.152.77.50 12345 11071 SA 11:09:41.854 R TCP 164.152.77.50 164.152.77.217 11071 12345 R |
그림 1 – 사전 17.1 또는 비 POSIX 게시물 17.1을 수락
응용 프로그램이 POSIX 기반인 경우 상황이 다릅니다(그림 2). STCP는 연결 요청(S)에 즉시 회신합니다(SA). 그런 다음 300초 후에 응용 프로그램이 깨어나고 통화가 수락되고 STCP가 허용된 소켓을 반환합니다.
수락테스트위드포식스 12345 실행 수락테스트노포식스 12345 300초 동안 수면 10:58:43.962 R TCP 164.152.77.50 164.152.77.217 11024 12345 S 10:58:43.964 TCp 164.152.77.217 164.152.77.50 12345 11024 SA 10:58:43.964 R TCP 164.152.77.50 164.152.77.217 11024 12345 A 포트 번호 12345에서 연결을 수락할 준비가 되었습니다. 연결 수락 |
그림 2 – POSIX 기반 게시물 17.1 수락
동작 차이는 중요할 수 있습니다. 클라이언트가 연결을 만든 후 서버 응용 프로그램에서 응답을 기대하는 경우 응용 프로그램이 실제로 호출하기 전에 시간 종료 하고 연결을 닫을 수 있습니다.
POSIX를 통해 응용 프로그램을 빌드하려면 어떻게 해야 합니까? 첫 번째 줄
#define _POSIX_C_SOURCE 200112L |
응용 프로그램 소스의 첫 번째 줄이어야 합니다. 두 번째 라이브러리 경로
(master_disk)>시스템>posix_object_library
STCP 라이브러리 후 와 C 라이브러리 앞에 개체 라이브러리 경로에 있어야 합니다.
이 작업이 수행되었는지 어떻게 알 수 있습니까? 응용 프로그램이 display_program_module-object_dirs 명령을 사용하여 바인딩된 개체 라이브러리를 볼 수 있습니다.
display_program_module 수락테스트위드포식스 -object_dirs
%아즈보스 #m17_mas>시스관리자>Noah_Davids>temp>수락TestwithPosix.pm
오브젝트 디렉토리 맵:
검색 디렉토리 11개
검색되지 않은 디렉터리 0개
모든 디렉토리 11개
DTC 디렉토리 경로
1 %아즈보스#m17_mas>시스관리자>Noah_Davids>temp
2 %아즈보스#m17_mas>시스템>stcp>object_library
3 %아즈보스#m17_mas>시스템>stcp>object_library>소켓
4 %아즈보스#m17_mas>시스템>stcp>object_library>net
5%아즈보스#m17_mas>시스템>stcp>object_library>보통
6 % 아즈보스 #m17_mas>시스템>posix_object_library
7%아즈보스#m17_mas>시스템>c_object_library
8 % 아즈보스 #m17_mas>시스템>object_library
9 %아즈보스 #m17_mas>옵트>아파치>리브
10% 아즈보스#m17_mas>옵트>는 열림
11%아즈보스#m17_mas>옵트>mysql>lib>mysql
|
그러나 #define 소스 코드의 일부인지 알 수 없습니다.
소켓 플래그를 볼 수 있는 코드를 실행할 수 있는 경우 POSIX 기반 프로그램에 SF_POSIX 소켓 플래그가 설정됩니다. 예를 들어, 나는 세 가지 프로그램을 수락TestnoPosix, 동의테스트와포식스와 수락테스트포식스패스만. 이 마지막 하나는 라이브러리 경로에 >system>posix_object_library 디렉터리를 가지고 있었지만 소스 코드에 #define 포함하지 않았습니다. 이는 잘못된 조합으로 간주됩니다. POSIX 라이브러리와 바인딩되어 코드에 POSIX_SOURCE #define 문이 있는 응용 프로그램만 SF_POSIX 플래그가 있는 소켓을 만들었습니다.
acceptTestnoPosix.pm 12345
실행 수락테스트노포식스 12345
300초 동안 수면
로: 일치 posix; dump_stcbq -전체 -lport 12345
로:
|
acceptTestwithPosix.pm 12345
실행 수락테스트노포식스 12345
300초 동안 수면
로: 일치 posix; dump_stcbq -전체 -lport 12345
SF_POSIX
로:
|
acceptTestwithPosixPathOnly.pm 12345
실행 수락테스트노포식스 12345
300초 동안 수면
로: 일치 posix; dump_stcbq -전체 -lport 12345
로:
|
네 번째 가능성이 있다, #define 소스에 포함 되었지만 posix_object_library 사용 되지 않았습니다. 이 경우 소켓 루틴이 오류를 반환합니다.
수락테스트더포식스정의만 12345 실행 수락테스트노포식스 12345 수락테스트노포식스: 청취 소켓을 만들 수 없습니다: 응용 프로그램 빌드 + 잘못 : POSIX 런타임은 C 런타임 전에 검색해야합니다. |
STCP 명령 및 유틸리티의 모든 POSIX와 함께 구축 하 고 강력 하 게 당신이 구축 하는 모든 응용 프로그램 POSIX를 사용 하는 것이 좋습니다.