Archive

---

• 이 내용은 2004/04/21 기준으로 쓰여졌습니다. 최신 내용은 본가에서 얻으실 수 있습니다.

---

개념

모든 Embryo 는 SSTP 서버로서의 기능을 가집니다. SSTP 서버는 SSTP 클라이언트와 일정한 프로토콜로 통신을 해, 리퀘스트에 따라 여러가지 동작을 합니다. 이 구조에 의해 어떠한 프로그램에서도 Embryo를 이벤트등의 「표현 수단」으로 사용하거나 혹은 가짜 AI에 적절한 정보를 주는 것으로 가짜 AI의 잠재력을 보다 강하게 끌어내거나 하는 것이 가능하게 됩니다.

이 서비스는 OS에 의존하지 않는 형태로 행해지기 때문에, 송신 가능성은 로컬 머신 내에서만으로 한정되지 않습니다. 인터넷등을 경유 해 다른 머신의 클라이언트로부터 다른 머신의 Embryo 에 SSTP 패킷을 송부하는 것이나, web 서버로부터 클라이언트 머신에 대해서 SSTP 패킷을 송신하는 것 등도 가능합니다.

동작

Embryo는 포트 9801번을 리스닝 합니다. (주: SSP외 기타 본체 호환 모듈에서는 포트 9821, 11000 등도 사용합니다. 기본적으로 사용되는 것은 9801번.) 클라이언트는 이 포트에 접속해, SSTP 프로토콜로 패킷을 보냅니다. 보낸 후, 리퀘스트가 올바른가 그렇지 않은가에 상관없이 약 2초 이내에 스테이터스 코드가 돌아가, 리퀘스트가 올바르면 Embryo 는 패킷으로부터 데이타를 추출해 내고 적절한 동작을 합니다.

하나의 서버(본체)에 접속 할 수 있는 클라이언트(SSTP 송신자)는 하나만으로, 이미 클라이언트가 있는 경우 Conflict 가 돌아갑니다. 통신은 지극히 단시간에 종료하는 것을 전제로 하고 있어 종료되지 않은 경우는 Request Timeout으로 강제로 끊깁니다.

SSTP 프로토콜 사양

문자 코드

리퀘스트 본체와 기본적인 헤더(DBCS 가 필요없는 헤더)는 ASCII 코드만으로 구성됩니다.

Sender/Script/Document/Songname/Sentence 등 ASCII 코드만으로는 사용 불가능한 헤더내의 캐릭터 라인에는 다음과 같은 캐릭터 세트 및 encode를 사용 할 수 있습니다.

ASCII 
Shift_JIS 
ISO-2022-JP 
EUC-JP 
UTF-8 

이것들은 명시적으로 지정하지 않으면 안됩니다.

지정은 다음과 같이 합니다.

SEND SSTP/1.1 
Sender: 카드캡터 
Script: \0\s0 너의 본모습으로 돌아가라. \e 
Option: nodescript, notranslate 
Charset: UTF-8 

[EOD] (데이타의 끝. 실제 데이타는 아니다.)

이와 같이 기술하면 Sender 및 Script 헤더는 UTF-8 로서 해석되어 Embryo 도착 시점에서 내부 코드(환경 의존 코드)로 변환됩니다.

Charset 에 ASCII 를 지정할 경우, 송신된 캐릭터 라인은 어떠한 변환도 행해지지 않습니다.

(주: Ukagaka시리즈, 곧 본가 Embryo 및 Materia시리즈에서는 Charset에 어떤 데이타가 들어오든지 기본적으로 Shift_JIS 코드로 변환이 되는 것 같습니다. 특히 UTF-8 코드는 whoami 표현으로 "사꾸라 스크립트" (사쿠라가 아닌... -_-;) 라는 코드로 변환되는데, 모든 코드는 SakuraScript \_u[0x****] 의 형식으로 표현됩니다. 기타 다른 본체들에서는 그냥 UTF-8 코드 그대로 사용되는 것 같습니다. 자세한 사항은 각 본체 홈페이지 등을 참조.)

NOTIFY/1.0

{{{ * 예제 NOTIFY SSTP/1.0 Sender: 사쿠라 Event: OnMusicPlay Reference0: 원조 타카기 부- 전설 Reference1: 근육소녀대 Charset: Shift_JIS

[EOD] }}}

NOTIFY/1.0 은 범용적인 이벤트 통지를 행하기 위한 리퀘스트입니다. NOTIFY 로 건네받은 데이터는 SSTP 서버를 통해 SHIORI/2.2 리퀘스트로서 Shiori에 도달해, Shiori는 이벤트에 대한 반응을 합니다.

NOTIFY 를 이용하는 SSTP 클라이언트를 작성하기 전에, 프로그래머는 Shiori가 어떠한 구조로 이벤트에 반응을 하는 것인가를 반드시 알아 둘 필요는 없습니다. 그러나 알아 두는 편이 전체의 구조를 이해하기 쉬워집니다.

→ SHIORI/2. 2 사양서 (SpecShiori2)

인수

• Event

  • 이벤트 식별자

• Reference* (0 ~ 7)

  • 참조 정보

이벤트 식별자는 Shiori가 이벤트의 종류를 판단할 때에 사용됩니다. 명명 규칙은 특별히 없습니다만, 간결하고 독특한 이름으로 해 주세요.

참조 정보 헤더에는 이벤트를 올바르게 해석하는데 있어서 필요한 배경 정보를 기입합니다. 예를 들면 상기의 예에서는 음악 재생 개시 이벤트 OnMusicPlay 에 곡명과 아티스트명이 참조 정보로서 주어지고 있습니다. 이러한 배려를 하는 것으로 Shiori는 보다 정확한 반응을 할 수가 있습니다.

NOTIFY/1.1

{{{ * 예제 NOTIFY SSTP/1.1 Sender: 사쿠라 Event: OnMusicPlay Reference0: 원조 타카기 부- 전설 Reference1: 근육소녀대 IfGhost: 나루, 유우카 Script: \h\s0‥‥\w8\w8타카기 부- 이지. \u\s0‥‥\e IfGhost: 사쿠라, 우뉴 Script: \h\s0‥‥\w8\w8타카기 부- 이지. \u\s0뭐‥‥\w8\w8. \e Charset: Shift_JIS

[EOD] }}}

NOTIFY/1.1 은 보험 반응 첨부 이벤트 통지를 행하기 위한 리퀘스트입니다. 기본적인 동작은 NOTIFY/1.0 과 같습니다만, Shiori가 해당 이벤트를 해석하지 못했을때 (무반응이었다거나)는 Script 헤더로 식별되는 스크립트가 표시됩니다.

NOTIFY/1.1 은 NOTIFY/1.0 과 SEND/1.0 ~ SEND/1.4 의 이점 모두를 겸비해, 고유의 Shiori의 존재와도 모순되지 않는 완전한 이벤트 통지 리퀘스트입니다. 현재 이벤트 통지를 위해 SEND 를 사용하고 있는 모든 SSTP 클라이언트는 SEND 리퀘스트의 사용을 중지하고 모든 이벤트에 독자적인 식별자를 주어 그것을 NOFITY/1.1 로 송신하지 않으면 안됩니다. 또 향후 새롭게 작성되는 SSTP 클라이언트는 이벤트 통지때 반드시 NOTIFY 리퀘스트를 사용하지 않으면 안됩니다.

NOTIFY/1.1 의 사양은 NOTIFY/1.0 과 SEND/1.0 ~ SEND/1.4 의 사양인 채입니다. 각 리퀘스트 고유의 헤더에 대해서는 각각의 사양서를 참조해 주세요.

(주: NOTIFY/1.1은, 다음에 나올 SEND 리퀘스트 형식을 보면 알겠지만, NOTIFY와 SEND의 모든 기능을 아우르고 있는 리퀘스트입니다. 원래 본가에서는 SEND와 NOTIFY는 사장시켜 버리고 NOTIFY/1.1로 통합시키려 했던 듯 하지만, 이런 리퀘스트의 주요 고객(?)인 가사표시 프로그램 "유나 섹시폰트" 가 이전 사양에서 더이상 버전업되지도 않을 뿐더러 하위 호환성 및 다른 본체와의 호환성, 본가의 Materia 개발 중단 등의 이유로 오히려 NOTIFY/1.1은 잘 사용되지 않습니다.. 따라서 SSTP 클라이언트 개발자분들에게는 NOTIFY와 SEND 두 기능을 선택해서 사용할 수 있도록 프로그래밍하는 것을 권장합니다)

SEND/1.1

SEND SSTP/1.1 
Sender: 카드캡터 
Script: \0\s0 너의 본모습으로 돌아가라. \e 
Option: nodescript, notranslate 
Charset: Shift_JIS 

[EOD] 

SEND 리퀘스트는 Embryo 스크립트 송신만을 목적으로 한 리퀘스트입니다. Script 헤더로 보내진 데이터가 그대로 스크립트로서 해석되어 대사로서 발언됩니다.

개행 코드는 CR+LF 입니다. 마지막에 공행을 보내면 통신 종료가 되어, 서버측으로부터 스테이터스 코드와 필요가 있으면 추가 데이터가 돌아갑니다. 추가 데이터는 Shift_JIS로 돌아갑니다.

각 헤더의 의미는 이하와 같습니다.

• Sender

  • 보내는 쪽의 프로그램명

• Script

  • 표시하는 스크립트

• Option

  • 옵션 스위치

Sender 및 Script 는 필수입니다. 어느 쪽이 빠져도 Bad Request 가 됩니다. 나머지 헤더는 생략 가능합니다.

---

Option 헤더로 사용 할 수 있는 커멘드는 다음과 같습니다.

• nodescript

  • SSTP 마커를 표시하지 않는다

• notranslate

  • 트랜스레이트(Translate; Makoto를 사용한 번역)를 하지 않는다

nodescript 옵션을 사용하면 SSTP 마커를 표시하지 않고 스크립트를 표시할 수가 있습니다. 다만 이 스위치는 로컬 머신으로부터의 리퀘스트만 유효합니다. 외부로부터의 송신에 대해서는 이 스위치의 설정에 관련되지 않고 항상 SSTP 마커가 표시됩니다.

notranslate 옵션을 설정하면 해당 스크립트는 트랜스레이트하지 않고 표시됩니다.

SEND/1.2

SEND SSTP/1.2 
Sender: 카드캡터 
Script: \h\s0 어떤 느낌? \n\n\q0[#temp0][그저]\q1[#temp1][지금 하나]\z 
Entry: #temp0, \h\s0으-음. \e 
Entry: #temp1, \h\s0술로 도망치게 되는것!\e 
Charset: Shift_JIS 

[EOD] 

SEND/1.2 는 선택지 인터페이스를 실현하기 위한 사양입니다. 상기의 예에서는 Embryo 는 2 분기의 선택지를 표시해, 「그저」를 선택하면 서버상에서 「으-음」이라고 하는 대사가 발언되어 동시에 클라이언트에는 「그저」라고 하는 반환값이 돌아갑니다.

반환값은 Shift_JIS로 돌아갑니다.

서버상에서 선택지가 선택될 때까지 쌍방의 처리는 기본적으로 블록 됩니다. 이 케이스에서는 SSTP의 2초 룰은 적용되지 않고, 반환값을 얻을 수 있을 때까지 서버는 응답을 돌려주지 않습니다. 올바르게 선택지가 선택될 경우는 200 및 반환값이, 타임 아웃 할 경우는 204 가, SSTP 브레이크를 받을 경우는 210 이 돌아갑니다.

추가된 각 헤더의 의미는 이하와 같습니다.

* Entry

• 일시적 엔트리

Entry 헤더로 보내진 엔트리는 그 세션 1회에 한해 일시적인 스크립트로서 서버에 저장 됩니다. embryo 스크립트에 있어서의 엔트리와 스크립트의 관계는 스크립트 레퍼런스(SpecSakuraScript)를 참조해 주세요. 일시적 스크립트는 세션중 완전한 엔트리로서 기능합니다만, 세션이 종료하는 대로 모두 파기 됩니다. 권한은 SSTP 와 동레벨로 위험한 태그는 통과하지 않습니다.

SEND/1.3

SEND SSTP/1.3 
Sender: 카드캡터 
HWnd: 1024 
Script: \h\s0 어떤 느낌? \n\n\q0[#temp0][그저]\q1[#temp1][지금 하나]\z 
Entry: #temp0, \m[1025,0,0]\h\s0으-음. \m[1025,0,1]\e 
Entry: #temp1, \m[1025,1,0]\h\s0술로 도망치게 되는것!\m[1025,1,1]\e 
Charset: Shift_JIS 

[EOD] 

SEND/1.3 은 윈도우 메시징에 의해 클라이언트가 embryo 의 동작 상황을 세밀하게 파악 하기 위한 사양입니다. Windows라는 고유의 OS에 편중된 내용이라서, 약간 이색적인 사양입니다.

상기의 예에서는 embryo 는 2 분기의 선택지를 표시해, 「그저」를 선택하면 서버상에서 「으-음」이라고 하는 대사가 발언되어 그 표시가 종료하는 것과 동시에 PostMessage(1024,1025,0,0)가 실행됩니다. 이와 같이 「지금 하나」를 선택하면 PostMessage(1024,1025,1,0)가 실행됩니다. 이러한 동작에 의해 클라이언트는 embryo 스크립트 디코더가 지금 어디를 읽고 있는 것인가를 100%완전하게 알 수 있습니다.

추가된 각 헤더의 의미는 이하와 같습니다.

• HWnd

  • 윈도우 핸들

HWnd 헤더는 이후의 \m 태그의 메세지 송부를 받는 윈도우 핸들입니다. 적절한 윈도우 프로시저를 가지는 핸들을 지정해 주세요.

SEND/1.4

SEND SSTP/1.4 
Sender: 카드캡터 
IfGhost: 사쿠라, 우뉴
Script: \h\s0사쿠라다-. \w8\n\n%j[#mainblock] 
IfGhost: 세리코, 마루치
Script: \h\s0세리코다-. \w8\n\n%j[#mainblock] 
IfGhost: 사쿠라, 케로 
Script: \u\s0나는 모던 구이로 할거야~. \w8\h\s0네에네에. \e 
Entry: #mainblock, \s7잠꼬대는 잘 때나 해!\w8\u\s0 진정해!\e 
Charset: Shift_JIS 

[EOD] 

SEND/1.4 는 고유의 고스트에 최적화된 시나리오를 송신 하기 위한 사양입니다.

상기의 예에서는, 고우스트가 사쿠라였던 경우는 「사쿠라다-」, 세리코였던 경우는 「세리코다-」라고 발언해, 그 후 양쪽 모두에 공통되는 본문이 계속됩니다. 사쿠라도 세리코도 아니었던 경우, 그 고스트가 allowembryo ==1 이라면 사쿠라＆우뉴의 대사를 말하며(종래대로의 동작), allowembryo==0 이라면 Refuse 가 돌아갑니다(고스트가 대사를 거부). SSTP/1.4 는 이 구조에 의해 「SSTP 때문에 고스트의 이미지가 부수어진다」라고 하는 문제에 대해서 선택지를 제시하고 있습니다.

allowembryo 설정에 대해서는 쉘 문서(SpecShell)를 참조해 주세요.

추가된 각 헤더의 의미는 이하와 같습니다.

• IfGhost

  • 대상이 되는 고우스트명

IfGhost 헤더는 [name],[name] 의 형식으로 지정해, 첫번째가 본체측, 2번째가 우뉴측의 이름입니다. 이것은 대문자 소문자 등을 포함하여 완전하게 일치할 필요가 있습니다.

EXECUTE/1.0

{{{ * 예제 EXECUTE SSTP/1.0 Sender: 샘플 프로그램 Command: GetName Charset: Shift_JIS

[EOD] }}}

EXECUTE 리퀘스트는(주로 출력을 수반하지 않는다) 범용적인 커맨드 실행을 목적으로 한 리퀘스트입니다.

각 헤더의 의미는 이하와 같습니다.

• Sender

  • 보내는 쪽의 프로그램명

• Command

  • 실행하는 커멘드

이 2개는 필수입니다. 어느 쪽이 빠져도 Bad Request 가 됩니다.

개행 코드는 CR+LF 입니다. 마지막에 공행을 보내면 통신 종료가 되어, 서버측으로부터 스테이터스 코드와 필요가 있으면 추가 데이터가 돌아갑니다. 추가 데이터는 Shift_JIS로 돌아갑니다.

Command 헤더로 사용 할 수 있는 커맨드는 이하와 같습니다.

• GetName

  • 캐릭터의 이름 취득

GetName 커맨드를 보내면 현재 동작중인 캐릭터의 이름이 돌아갑니다. 클라이언트는 이 데이터를 취득하는 것으로 현재 서버가 「누구」인지 알 수 있어 캐릭터에 의해 대사의 내용을 바꾸거나 혹은 송신을 중지하거나 할 수가 있습니다.

실장되어 있지 않은 커멘드를 보내면 Not Implemented 가 돌아갑니다.

EXECUTE/1.1

{{{ * 예제 1 EXECUTE SSTP/1.1 Sender: 카드캡터 Command: SetCookie[visitcount, 1] Charset: Shift_JIS

[EOD] }}}

{{{ * 예제 2 EXECUTE SSTP/1.1 Sender: 카드캡터 Command: GetCookie[visitcount] Charset: Shift_JIS

[EOD] }}}

EXECUTE/1.1 은 긴 수명을 가지는 변수의 보관 유지를 목적으로 한 리퀘스트입니다. SSTP 는 이것을 이른바 Cookie 동작에 의해 실현됩니다.

추가 헤더는 없습니다.

추가된 커멘드는 이하와 같습니다.

• SetCookie[entry, value]

  • 쿠키를 저장함

• GetCookie[entry]

  • 쿠키의 내용을 가져옴

적절한 인수를 설정해 SetCookie 를 보내면 그 데이터가 서버에 저장됩니다. 저장한 데이터는 GetCookie 로 꺼낼 수가 있습니다.

저장된 데이터는 쓴 클라이언트 자신만이 읽어낼 수 있으므로 주의해 주세요. 예를 들면 A 라고 하는 서버가 격납 한 visitcount 라고 하는 데이터를 B 라고 하는 서버가 읽어내려고 해도 실패합니다. 이것은 보안 보관 유지와 변수명 충돌 회피의 2가지 목적이 있습니다.

Get 하려고 한 데이터가 존재하지 않는 경우는 null은 아니고 No Content 가 돌아갑니다.

EXECUTE/1.2

{{{ * 예제 EXECUTE SSTP/1.2 Sender: 카드캡터 Command: GetVersion Charset: Shift_JIS

[EOD] }}}

EXECUTE/1.2 는 본체 버젼 식별을 목적으로 한 리퀘스트입니다.

추가 헤더는 없습니다.

추가된 커맨드는 이하와 같습니다.

• GetVersion

  • 버젼 취득

GetVersion 을 지시 하면, SSTP 서버는 버젼을 식별 할 수 있는 캐릭터 라인을 돌려줍니다. 그것은 예를 들면 다음과 같은 것입니다.

• "inverse" 17.00

EXECUTE/1.3

{{{ * 예제 EXECUTE SSTP/1.3 Sender: 카드캡터 Command: Quiet Charset: Shift_JIS

[EOD] }}}

EXECUTE/1.3 은 본체를 조용하게 시키는 리퀘스트입니다.

추가 헤더는 없습니다.

추가된 커맨드는 이하와 같습니다.

• Quiet

  • 조용하게 시킨다

• Restore

  • 원래대로 돌린다

Quiet 를 지시 하면 서버는 당분간 자신의 의지로 말하지 않게 됩니다. 즉, 연속한 SEND 를 보내는 것을 알고 있는 경우(인격이 크게 SSTP 클라이언트 측에 의존하는 경우), 최초로 Quiet을 지시 하는 것으로 그 연속적 발언을 방해받지 않게 할 수 있습니다.

Quiet 세션은 Restore 가 지시받거나, 혹은 리퀘스트 없음으로 약 16 초간 방치하는 것으로 해제됩니다.

서버에 Quiet 를 지시 할 수 있는 것은, 현단계에서는 서버와 동일한 IP 를 가지는 클라이언트만입니다.

GIVE/1.0

이 리퀘스트는 더이상 사용되지 않습니다

{{{ * 예제 GIVE SSTP/1.1 Sender: 카드캡터 Document: 안녕하세요 사쿠라입니다. 어둠의 힘을 가진 열쇠여 진정한 모습으로 내 앞에 나타나라 릴리-즈. 너의 본모습으로 돌아가라 크로우카-드. Charset: Shift_JIS

[EOD] }}}

GIVE 리퀘스트는 embryo 에 데이터를 주어 그것을 처리 시키거나 혹은 반응 시키거나 하는 리퀘스트입니다.

이 리퀘스트는 현단계에서는 로컬 머신으로부터의 리퀘스트에 한정합니다(밖으로부터 온 것은 거부합니다).

각 헤더의 의미는 다음과 같습니다.

• Sender

  • 보내는 쪽의 프로그램명

• Document

  • 문서

• Songname

  • 곡명

Sender와 몇개의 소스 데이터, 이 2가지는 필수입니다. 어느 쪽이 빠져도 Bad Request 가 됩니다. 소스 데이터가 다수 있는 경우는 어느쪽이든 하나가 우선됩니다.

개행 코드는 CR+LF 입니다. 마지막에 공행을 보내면 통신 종료가 되어, 서버측으로부터 스테이터스 코드가 돌아갑니다.

소스 데이터의 종류 및 그에 대하는 서버의 동작은 이하와 같습니다.

• Document

  • 임의의 문장

• Songname 곡명

Document는 문장 데이터입니다. embryo 는 보내진 데이터로부터 자신을 이해할 수 있는 단어를 주워, 그것을 이후의 회화에 활용합니다. 보낸 데이터가 올바르게 학습되어 있을지 어떨지는 AI스테이트 다이얼로그로 확인 할 수 있습니다.

Songname은 곡명입니다. embryo 는 보내진 곡명을 song 데이타베이스와 조합해, 히트 하면 그 곡에 대한 어떠한 발언을 합니다(song 오버라이드(override) 사양서를 참조해 주세요). 이 처리는 리퀘스트 수리 후 즉석에서 행해집니다. (주: song 오버라이드 사양서는 일단은 금시초문. 혹시 자료가 있으면 주석을 붙여 주세요)

보내는 문자의 문자 코드는 묻지 않습니다. html등의 서식 기호가 포함되어도 상관하지 않습니다. 모두 서버측에서 대응합니다.

COMMUNICATE/1.1

{{{ * 예제 COMMUNICATE SSTP/1.1 Sender: 카드캡터 Sentence: 오늘은 춥네-. Option: substitute Charset: Shift_JIS

[EOD] }}}

COMMUNICATE 리퀘스트는 가짜 AI에 질문이나 동의를 요구하는 문장 등을 보내, 거기에 대답하게 해 필요가 있으면 대답을 받는 리퀘스트입니다. 주로 유저와의 대화나 다른 인공지능과의 회화에서의 사용을 상정하고 있습니다.

이 리퀘스트는 현단계에서는 로컬 머신으로부터의 리퀘스트에 한정합니다(밖으로부터 온 것은 거부합니다).

각 헤더의 의미는 다음과 같습니다.

• Sender

  • 보내는 쪽의 프로그램명

• Sentence

  • 문장

• Option

  • 옵션

Sender 와 Sentence는 필수입니다. 어느 쪽이 빠져도 Bad Request 가 됩니다.

개행 코드는 CR+LF 입니다. 마지막에 공행을 보내면 통신 종료가 되어, 서버측으로부터 스테이터스 코드와 필요가 있으면 추가 데이터가 돌아갑니다.

보내는 문자의 문자 코드는 묻지 않습니다. 서버측에서 대응합니다.

Option 헤더로 사용 할 수 있는 커맨드는 이하와 같습니다.

• substitute

  • 우뉴측에게 Sentence 헤더를 말하게 한다

substitute 옵션을 사용하면 Sentence 문자열을 우뉴가 대사로서 발언합니다. 이 구조에 의해, 대사의 발언 능력이 없는 클라이언트가 COMMUNICATE 리퀘스트를 이용할 때, 우뉴를 대사의 대리 발언자로서 이용할 수가 있습니다.

COMMUNICATE/1.2

{{{ * 예제

COMMUNICATE SSTP/1.2 Sender: 후타바 HWnd: 0 Sentence: \0\s0 안녕. \e Surface: 0,10 Reference0: N/A Charset: Shift_JIS

[EOD] }}}

COMMUNICATE/1.2 는 2 서버간에서의 대화를 행하기 위한 사양입니다. 이 사양은 SHIORI/2.3 의 존재와 지극히 깊은 관계가 있습니다. 이 리퀘스트는 SSTP 서버이며 또한 Shiori 서버이기도 한 서버 프로그램(예를 들면 embryo) 이외에는 사용이 되지 않습니다.

참조 : SHIORI/2. 3 시방서 (SpecShiori2)

embryo 는 COMMUNICATE/1.2 리퀘스트에 대한 SHIORI 의 대답을 Port 혹은 HWnd 헤더로부터 얻을 수 있는 송신측 서버(이야기한 서버)에 돌려 보냅니다. 이 구조에 의해 2 서버는 사실상의 회화를 합니다.

이 리퀘스트는 현단계에서는 로컬 머신으로부터의 리퀘스트에 한정합니다.

• Sender

  • 보내는 사람의 프로그램명

• Sentence

  • 문장

• Option

  • 옵션

• Port

  • 대답을 받는 서버(이야기하는 쪽)의 서비스 포트

• HWnd

  • 대답을 받는 서버(이야기하는 쪽)의 윈도우 핸들

• Surface

  • 대답을 받는 서버(이야기하는 쪽)의 현재의 surface ID, 왼쪽으로부터, sakura, kero

• Reference*

  • 대답을 받는 서버(이야기하는 쪽)가 보내는 임의의 추가 정보

스테이터스 코드

2xx - 처리 완료 

200 OK  
 정상적으로 종료했다  
204 No Content  
 정상적으로 종료했지만 돌리는 데이터가 없다  
210 Break  
 SSTP 브레이크 되었다  

4xx - 리퀘스트 에러 

400 Bad Request  
 리퀘스트 미비  
408 Request Timeout  
 타임 아웃  
409 Conflict  
 이미 다른 클라이언트가 접속하고 있다, 혹은 타임 크리티컬 세션중 (타이밍이 중요한 어떤 일을 하는 중)
420 Refuse  
 고스트가 SSTP 의 수신을 거부  

5xx - 서버 에러 

501 Not Implemented  
 서버가 해당 커맨드를 제공하고 있지 않다  
503 Service Unavailable  
 서버가 리퀘스트를 받지 않도록 설정되어 있다
510 Not Local IP  
 서버가 로컬 IP로부터의 리퀘스트 밖에 받지 않는 설정  
511 In Black List  
 서버의 블랙 리스트에 들어가 있다  
512 Invisible  
 서버가 메세지를 표시할 수 없는 상태(이므로 보내도 헛됨) 

한계

통신은 접속 종료후 서버측의 로컬 타임에 최대한 2초 이내에 종료할 필요가 있습니다. 2초에 끝나지 않는다면 Request Timeout 이 돌아가 강제로 통신 중지 됩니다.

리퀘스트 헤더의 최대 길이는 2 KB=2048 바이트(로컬 머신으로부터는 16 KB=16384 바이트)로 제한되어 있습니다. 이것보다 긴 헤더를 보내면 Bad Request 가 되어 즉시 중지 됩니다.

샘플 코드

※주의： 다음 샘플은 어디까지나 알고리즘을 이해 하기 위한 단순한 샘플 코드이고, 실제로는 사용할 수 없습니다. 결함이 있습니다.

{{{ * Perl

sub sendsstp {

• use Socket; $script=$_[0]; $sender='카드캐프타'; $port=9801; $addr=$ENV{'HTTP_X_FORWARDED_FOR'}; if (index($addr, '. ')==-1) { $addr = $ENV{'REMOTE_ADDR'}; } $proto = getprotobyname('tcp'); socket(S, PF_INET, SOCK_STREAM, $proto); $ent = sockaddr_in($port, inet_aton($addr));

  connect(S, $ent) || die; select(S); $| = 1; select(STDOUT); print S "SEND SSTP/1.1\r\n"; print S "Sender: $sender\r\n"; print S "Script: $script\\e\r\n"; print S "\r\n";

  $result = <S>; while (<S>) { print; } close(S); return($result);

}

...

$s=sendsstp('\0\s0‥‥\e');

...

}}}

반환값은 반드시 필요하지는 않기 때문에,

<img src="http://..../sstp.cgi" width=1 height=1>

이런 식으로 실행시키는 방법도 있습니다.

embryo 의 존재를 Low cost(시스템에 부하를 주지 않고)로 확인하는 방법

MUTEX

MUTEX "sakura" 의 존재를 체크하는 것으로 확실히 존재를 확인할 수 있습니다. 메모리 오브젝트의 문서(SpecMemoryObject)를 참조해 주세요.

---

CategorySpec

---