이번에는 Session Layer(흔히 세션 계층이라 부름) 에서의 데이터의 흐름을 분석할 때, 반드시 알아야만 하는 것들에 대해 적었다.
세션 계층은 상위 리소스 계층과 아래 전송 계층 사이에서 데이터를 주고 받게 하는 역할을 한다.
또한 하부에서 올라오는 데이터들이 어느 리소스로 보낼 것인가를 결정한다. 모든 리소스는 POD 의 요구에 의해 OPEN 되어 지고, 시스템에서는 요구된 리소스의 OPEN 가능한가에 대한 응답을 보낸다. 이것 역시, 여러개의 Object Tag 가 존재한다.

1. open_session_request : application 에게 전송할 connection 이 리소스의 사용을 호스트에 요청하는 것이다.
2. open_session_reponse : 요구를 충족하지 못하는 모듈에게 얘기하거나, 리소스에 할당된 세션 넘버를 요청하는 application 에게 호스트가 대답하는 신호이다.
3. create_session : 다른 transport connection 의 application 으로 부터 차례로 확장 세션의 모듈안에 리소스 제공자에게 호스트를 보내는 것
4. create_session_response : 모듈이 시작해서 세션이 열리고,host 가 통신할 수 있으면, 모듈이 host 로 리소스 제공자가 대답하는 신호이다.
5. close_session_request : 모듈이나 호스트가 세션이 닫힐 때, 나오는 신호이다.
6. close_session_response : 모듈이나 호스트가 세션이 닫히는 것을 승인한다.
7. 세션 넘버는 언제나 APDU 가 포함되어 있는 SPDU 의 body 에 앞에 있다.

세션 계층에서 주고 받는 SPDU 의 기본 스펙은 다음과 같다.

위의 표에서 spdu_tag, length_field, sess_obj_value 가 Session 헤더부분이다. 나머지 부분이 Body 이다.
SPDU 는 크게 두 부분으로 나눌 수 있다.

1. 명령 헤더 부분은 spdu_tag, length_field, sess_obj_value 로 이루어져 있다.
2. 같은 세션에 속하는 APDU 의 정수에 포함되는 변수(variable) 길이는 body 이다. body 가 있으면, 세션 헤더에 의존한다.
3. SPDU 하나 안에는 제한된 갯수의 APDU 가 들어 있다.

위에 resource_identifler() 을 설명하자면, 총 4 byte 로 이루어져 있다. 이것은 아래와 같이 나뉘어져 있는 데, 가장 처음의 resource_id_type 의 값이 0,1,2 이면 public resource 이고, 3 이면 private resource 이다. resource_type 의 값은 0 이다.

위의 스펙에서 session_status 에 대한 설명이다. 현재 세션의 상태를 나타낸다.

resource_identifler : 현재의 버전 넘버와 함께 요청되어지는 리소스의가 실제의 리소스 인지 알려준다. 만일 응답이 '리소스는 존재하지 않음' 이라면, resource_identifler field 는 open 을 요청하게 될 것이다.

session_nb : 숫자는 호스트의 요청된 세션에 의해 정해진다. 값은 0 이 예약되어 있다. session_nb 는 차후에 세션이 닫힐 때까지의 리소스와 모듈 사이의 APDU 의 교환에 사용된다.

세션을 열지 못할 때(session_status 값이 0 이 아닐때), session_nb 는 아무 것도 아니다.

resource_identifier : 이 것은 현재의 버전 넘버와 함께 성공한 것과 리소스를 요청한 것에 대한 resource_identifier 이다.

session_nb : 이 것은 새로운 세션의 호스트에 의해 정해진 session number 이다.

session status values : open_session_response 의 내용과 같다.

resource_idenitfier : 모듈에 create_session_response class 와 요청된 리소스의 타입이 들어가 있다. 하지만 현재 제공되는 모듈의 버전 넘버는 들어가 있지 않다.

session_nb : 위의 create_session 의 session_nb 값과 동일 하다.

위의 스펙에 있는 session_status 을 설명하려면, 다음의 표를 봐야 한다.

이 오브젝트는 항상 APDU 가 포함된 SPDU 의 body 앞에 있다.

이 세션 계층은 가장 먼저 모듈에서 시작이 된다. 처음, 모듈에서 Topen_session_request 신호를 보내면, 호스트의 세션 계층에서 파싱을 한다. 이 계층은 파싱하는 것이 주 업무이다.
각각의 object_tag 를 보고, 어떻게 처리할지 결정한다.

총 4 가지의 루틴이 있는 데, 가장 먼저 open_session_request 에 대한 것이다. 호스트에서의 세션 계층은 모듈로 받은 데이터를 파싱해서 open_session_open 의 신호이면, 이 루틴이 가장 먼저 수행된다.
여기서는, 모듈의 신호에 대한 응답으로 open_session_response 를 내보낸다. 또한 세션이 open 되어 있다면, 바로 application 으로 보낸다.

이번에는 close_session_request 에 대한 것이다. 가장 먼저, 현재 열려 있는 윗단의 application 을 닫는다. 또한 이 신호에 대한 응답으로 close_session_reponse 신호를 내보낸다.

close_session_response 에 대한 것이다. 현재 세션의 상태를 확인한 뒤에, ssnb 를 지우고, 더 보낼 데이터가 있다면, T_RCV 신호를 보내고, 없다면, T_DATA_LAST 신호를 보낸다.

마지막으로 session_nb 에 대한 것이다. malloc 함수로 size 를 잡고, 보낼 데이터와 크기를 넣어서, 상위, 리소스 계층으로 보낸다.

이번에는 간단하지만 make_SPDU 에 대해서 알아보자!!
스펙에 나온 그대로, 메모리를 잡아서 , tag , length_field, 등등을 넣어서 전송 계층으로 보낸다.