"NANIKA(Temporary)"
Documents - sstp protocol -

SSTP Protocol Base Structure
  • contept
    All "SAKURA" have the ability to perform as a sstp server. A sstp server communicates to a sstp client by using a constant protocol, and performs various operations according to the request.
    With this structure, we can expect to following of "SAKURA":
    • Using an "Expression object".
    • Achieving better potential by giving appropriate information to the "faked AI (named Nise-AI)".
    Because this service is not dependant on OS, the possibility does not end at the local machine.
    for example:
    • sending a SSTP packet from a sstp client "SAKURA" tn a seperate machine via the internet.
    • sending a SSTP packet from a web server to the "SAKURA" of a client machine.
  • Operation
    "SAKURA" has a listening port of 9801(and/or port 7743). The client connects to this port, and sends packets using the sstp protocol. When client packet is sent, "SAKURA" returns a staus code within two seconds. If the packet is correct, "SAKURA" performs the request contained in the packet and executes the appropriate operation.
    One server can connect to only one client. If a server is already connected to another client, the server returns a conflict.
    The communication assumes that completion will be completed in a short time. Therefore if communication can not end in a short time, the server returns a timeout and forces a disconnect.

SSTP Protocol Definition
  • Character Set
     Requests the body and basic header(single byte character in the header only) using only ASCII code.
    Multibyte character required strings in headers(Sender/Script/Document/Songname/Sentence etc) can use the following character sets and encoding:
    • Shift_JIS
    • ISO-2022-JP
    • EUC-JP
    • UTF-8
    The charcter set must be defined. If the character set is not defined, the character set is currently assumed to be Shift_JIS, but this usage is not recommended.
    For example:
    SEND SSTP/1.1
Sender: CardCaptor
Script: \h\s0Return to your original appearance!!\e
Option: nodescript,notranslate
Charset: UTF-8

[EOD]
    In this example, the Sender and Script Header are defined to be using the UTF-8 encoding.
  • NOTYFY/1.0
     
    NOTIFY SSTP/1.0
Sender: SAKURA
Event: OnMusicPlay
Reference0: V
Reference1: TAKA
Charset: Shift_JIS

[EOD]
    NOTIFY/1.0 is used to notify of a general event. Data sent by NOTIFY reaches SHIORI as a SHIORI/2.2 request via the SSTP server. SHIORI will react to the event.
    To make a SSTP client using NOTIFY, a programmer need not necessarily learn the nature of the reactions by SHIORI. However, if you have learned SHIORI, the entire structure can be understood more easily.

    Please refer to the SHIORI/2.2 specification

    Header description
    • Event - Event identifier
    • Reference? - Reference information(? = 0 to 7)
    The event identifier is used by SHIORI to judge the kind of the event. There is no specific naming rule. However, simple and unique naming is recommended.
    Reference information is given on background information necessary to correctly judge an event. For example, the Reference information of the song name and singer is given to the event OnMusicPlay. Therefore, with such usage, SHIORI can react more appropriately.
  • NOTYFY/1.1
     
    NOTIFY SSTP/1.0
Sender: SAKURA
Event: OnMusicPlay
Reference0: V
Reference1: TAKA
IfGhost: naru,yuuka
Script: \h\s0....\w8\w8Oh, Finger feels itchy.\u\s0....\e
IfGhost: sakura,unyu
Script: \h\s0....\w8\w8Like very hard....\u\s0....\w8\w8? I can clear it.\e
Charset: Shift_JIS

[EOD]
    NOTIFY/1.1 is used to notify of a general event with an insurance event. The basic operation is same as NOTIFY/1.0, but if SHIORI does not have an identified event,(SHIORI doesn't react) the script is identified by the script header being displayed.
    NOTIFY/1.1 has the same priority as SEND/1.0 - SEND/1.4 and NOTIFY/1.0. When using NOTIFY/1.1, the use of a unique SHIORI is not required. NOTIFY/1.1 is a complete event notification request. All SSTP clients require the following:
    • stop SEND request for current event notification
    • all event add a unique identifier and must be sent with NOTIFY/1.1.
    In addition, any SSTP client which will be made in the future will be required to use NOTIFY/1.0 for event notification.
    The NOTIFY/1.1 specification is the same as SEND/1.0 - SEND/1.4 And NOTIFY/1.0. Please refer to each specification for the unique header of each request.
  • SEND/1.1
     
    SEND SSTP/1.1
Sender: CardCaptor
Script: \h\s0Return to your original appearance!!\e
Option: nodescript,notranslate
Charset: Shift_JIS

[EOD]
    SEND request is used to send only "SAKURA script". Sent data in script form is used to script as it is sent, and lines will be treated as sppech.
    The change line code is a carriage return(CR:0x0d) + line feed(LF:0x0a). Finally, when an empty line is sent, communication is ended, and the server returns a status code and additional data if any exists.
    Additional data encoding is Shift_JIS.

    Header description
    • Sender - Program name of sender
    • Script - script for display
    • Option - Option swich
    Both the Sender and Script are required. If either is not defined, the server returns a bad request. The remaining parts of the header are optional.
    *
    Option switch description
    • nodescript - SSTP maker is not displayed.
    • notranslate - does not translate.
    When the nodescript option is used, the script is displayed without the SSTP maker. Tthis option is effective only if the request is from the local machine. When the request is external, the SSTP maker is displayed even if the nodescript option is used.
    When the notranslate option is used, the script is displayed without performing any translation.
  • SEND/1.2
     
    SEND SSTP/1.2
Sender: CardCaptor
Script: \h\s0How are you feeling?\n\n\q0[#temp0][not bad]\q1[#temp1][a little bad]\z
Entry: #temp0,\h\s0Hmm...\e
Entry: #temp1,\h\s0DO NOT USE BEER TO ESCAPE!!\e
Charset: Shift_JIS

[EOD]
    SEND/1.2 is used to select the interface. This example displays two selections. If you select "not bad", the server displays "Hmm...", and the server returns a return value of "not bad".
    During the time that the selection is being made, both the server and client processes are blocked. For this, the "two second rule" is not applied and the server does not return a response at the point that the selection is decided. When a valid select is returned, server returns the status code "200" and the return value. When a timeout occurs, the server returns the status code "204". Finally, when a SSTP break is received, the server returns the status code "210".
    Added Header description
    • Entry temporary entry
    Entry sends the Entry header and is stored on the server as temporary script for this session. Please refer to the script references for the relation between "script" and "entry" in "SAKURA script". A temporary script will remain for the length of the session, but when the session is ended all temporary entries are destroyed. The authority level is same as SSTP and dangerous tags are rejected.
  • SEND/1.3
     
    SEND SSTP/1.3
Sender: CardCaptor
HWnd: 1024
Script: \h\s0How are you feeling?\n\n\q0[#temp0][not bad]\q1[#temp1][a little bad]\z
Entry: #temp0,\m[1025,0,0]\h\s0Hmm...\m[1025,0,1]\e
    
Entry: #temp1,\m[1025,1,0]\h\s0DO NOT USE BEER TO ESCAPE!!\m[1025,1,1]\e
Charset: Shift_JIS

[EOD]
    SEND/1.3 is used to check the state of "SAKURA" by using window messages.
    This specification is dependant on "Microsoft Windows". This example displays two selections. If you select "not bad", the server displays "Hmm...", and at the same time, postmessage(1024,1025,0,0) is executed. Likewise, if you select "a little bad", postmessage(1024,1025,1,0) is executed.
    Therefore, clients can be aware of the place that "SAKURA" is currently reading.
    Added Header description
    • HWnd handle of window
    HWnd header is the windows handle by which the message of "\m tag" is accepted. Please set the handle to have a valid window procedure.
  • SEND/1.4
     
    SEND SSTP/1.4
Sender: CardCaptor
IfGhost: sakura,unyu
Script: \h\s0Ah,sakura!!\w8\n\n%j[#mainblock]
IfGhost: seriko,multy
Script: \h\s0Oh,seriko!!\w8\n\n%j[#mainblock]
IfGhost: sakura,kero
Script: \u\s0Give me a baked modern!!\w8\h\s0ok ok..\e
Entry: #mainblock,\s7Talking in one's sleep at sleeply!!\w8\u\s0Calm down!!\e
Charset: Shift_JIS

[EOD]
    SEND/1.4 is used to send an optimized scenario to a specific ghost. In this example, if the ghost is sakura, the server displays "Ah,sakura!!" and the common strings. (#mainblock) If the ghost is seriko, the server displays "Oh,seriko!!" and the common strings. If the ghost is neither sakura nor seriko and if allowsakura == 1, the server displays the sakura/unyu lines(classic specification) else if allowsakura == 0, the server returns a Refuse.(The ghost rejects the display lines.)
    Please refer to the script references for the allowsakura definition.
    Added Header description
    • IfGhost Specific ghost name
    IfGhost is described in the form of "[name],[name]". The first item is name of main body, and second item is the name of the unyu body. The name should be completely corresponding including uppercase and lowercase characters.
  • EXECUTE/1.0
     
    EXECUTE SSTP/1.0
Sender: sample program
Command: GetName
Charset: Shift_JIS

[EOD]
    EXECUTE/1.0 is used to execute a generic command without output.
    Header description
    • Sender - Program name of sender
    • Command - execute command
    Both the Sender and Command are required. If either is not defined, the server returns a bad request.
    The change line code is a carriage return(CR:0x0d) + line feed(LF:0x0a). Finally, when an empty line is sent, communication is ended, and the server returns the status code and additional data that might exist.
    Additional data encoding is Shift_JIS.

    Command Header description
    • GetName - Get character name
    When the GetName command is sent, the server returns the active character name. The client can know the name of the server. The client can change the lines and the process of each character. (This includes canceling.)
    If the command sent is not implemented, the server returns "Not Implemented".
  • EXECUTE/1.1
     
    EXECUTE SSTP/1.1
Sender: CardCaptor
Command: Command: SetCookie[visitcount,1]
Charset: Shift_JIS

[EOD]

...
...

EXECUTE SSTP/1.1
Sender: CardCaptor
Command: Command: GetCookie[visitcount]
Charset: Shift_JIS

[EOD]
    EXECUTE/1.1 is used to keep a variable for a long time. SSTP implements this command using a "Cookie" proceess.

    This command does not have any added headers.

    Added command description
    • SetCookie[entry,value] - set value to cookie
    • GetCookie[entry] - get value from cookie
    When any parameter SetCookie command is sent, that parameter is stored on the server and this stored parameter can be retreived by GetCookie.
    Be careful because only the client which the parameter is stored on can retrieve the stored parameter.
    When another client attempts to retrieve the stored parameter, the retrieval fails. This is done for security reasons and to avoid variable name collision.
    If the GetCookie parameter does not exist, the server returns "No Content".(NOT NULL)
  • EXECUTE/1.2
     
    EXECUTE SSTP/1.2
Sender: CardCaptor
Command: GetVersion
Charset: Shift_JIS

[EOD]
    EXECUTE/1.2 is used to get the current "SAKURA" version.

    This command does not have any added headers.

    Added command description
    • GetVersion - get version
    When the GetVersion command is sent, the SSTP server returns a string which can identify the version.
    For example: "inverse" 17.00
  • EXECUTE/1.3
     
    EXECUTE SSTP/1.3
Sender: CardCaptor
Command: Quiet
Charset: Shift_JIS

[EOD]
    EXECUTE/1.3 is used to mute "SAKURA".

    This command does not have any added headers.

    Added command description
    • Quiet - Enable muting
    • Restore - cancel muting
    When the Quiet command is sent, the SSTP server will not speak under its own will. This command is useful for the following:
    • When continuous use of SEND is understood(character greatly depends on client), previous use of the Quiet Command will stop the continuous use of SEND.
    A Quiet session is released at when the Restore command is sent or by waiting for 16 seconds.
    At the present stage, only a client with the same IP address as the server can send Quiet to the server.
  • GIVE/1.0
     
    GIVE SSTP/1.1
Sender: CardCaptor
Document: Hello, my name is SAKURA. Release!! Return to your original appearance!! CLOW CARD!!
Charset: Shift_JIS

[EOD]
    GIVE/1.1 is used to give data to "SAKURA" to be processed or to react.
    Header description
    • Sender - Program name of sender
    • Document - Document
    • Songname - song name
    Both Sender and either Document or Songname are required. If neither is defined, the server returns a bad request.
    The line change code is a carriage return(CR:0x0d) + line feed(LF:0x0a). Finally, when an empty line is sent, communication is ended, and server returns the status code.
    Souce data description
    • Document - any Document
    • Songname - song name
    Document is the document data. "SAKURA" extracts understandable words from the sent data. It will used to talk in the future. To confirm that "SAKURA" is learning data, look in the "AI state dialog".
    Songname is a song name. "SAKURA" collates sent data and a song database. If Songname is found in the database, "SAKURA" says something about the found song. ( Please refer to song override.) After this request is received, the request is processed at once.
    The format code(html-tag etc.) and character-code of the characters sent correspond by server.
  • COMMUNICATE/1.1
     
    COMMUNICATE SSTP/1.1
Sender: CardCaptor
Sentence: Today is very cool.
Option: substitute
Charset: Shift_JIS

[EOD]
    COMMUNICATE/1.1 is used to send messages to the "faked AI". (Such as a question, agreement, a request, etc.) It returns any reaction and answer (when required). This request always assumes communication to another user or to another "faked AI".
    At the present time, this request can only be used from the local machine. (If this request is sent from another machine, it will be rejected.)
    Header description
    • Sender - Program name of sender
    • Sentence - Document
    • Option - Option swich
    Both Sender and Sentence are required. If either are not defined, the server returns a bad request.
    The change line code is a carriage return(CR:0x0d) + line feed(LF:0x0a). Finally, when an empty line is sent, communication is ended, and the server returns the status code and any additional data that might exist.
    The character-code of the sent characters correspond by server.
    *
    Option switch description
    • substitute - unyu says the content of Sentence.
    When using substitute, the unyu body says the content of Sentence. Therefore, a client without the speech function can request the speech agency to use the unyu for the COMMUNICATE request.
  • COMMUNICATE/1.2
     
    COMMUNICATE SSTP/1.2
Sender: SAKURA
Port: 10800
Sentence: \h\s0How are you feeling?\e
Charset: Shift_JIS

[EOD]
    COMMUNICATE/1.2 is used to talk between two servers. This request is dependant upon SHIORI/2.1. Only the SSTP server and the SHIORI server can use this request.(e.g. "SAKURA")

    Please refer to the SHIORI/2.1 specification

    "SAKURA" returns an answer from SHIORI/2.1 to the COMMUNICATION/1.2 request message sent to the server obtained from HWnd or Port. Therefore the two servers virtually talk.
    At the present time, this request can only be used from the local machine.
    Added Header description
    • Port Port number of answer from receiving side(Questioner side)
    • HWnd handle of window of answer from receiving side(Questioner side)
  • status code
    2xx - Process Complete
    200 OKNormal end
    204 No ContentNormal end, but no data was returned
    210 BreakSSTP Break occurred
    4xx - Request Error
    400 Bad RequestInvalid Request content
    408 Request TimeoutTimeout occurred while sending data
    409 ConflictAnother client is already connected or a time critical session is operating
    420 RefuseThe ghost rejected the SSTP
    5xx - Server Error
    501 Not ImplementedServer does not support the function that was requested.
    503 Service UnavailableServer is set not to accept the request that was sent.
    510 Not LocalIPServer is set to accept the request only from the local IP.
    511 In Black ListRequest was from a server registed in the server blacklist.
    512 InvisibleServer is in a state that is not able to display the message.(The request is useless even if sent.)
  • Reguration
     The communication time limit is two seconds on the server side timer. If the request can not be completed in under two seconds, the server returns a "Request Timeout" and forces a disconnect.

POISON WAVE
Note: This sample code is used to show the algorithm and is a very basic example. If this example code is used, you will likely receive complaints from various people. Therefore, please understand the structure and enhance the code yourself, or use good code written by a good programmer.
  • Perl
    sub sendsstp {

use Socket;

$script=$_[0];
$sender=' CardCaptor';

$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.0\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('\hAh!!\e');
    *
A return value is not necessary. Therefore, if the server cannot use CGI/SSI, send therequest from the other server using the following: 
<img src="http://www.koutetsutenshi.net/sstp.cgi" width=1 height=1>

How to check for the existence of "SAKURA" at a low cost
  • MUTEX
    If you check for the existence of the MUTEX "sakura", you can verify its existence. Please refer to the memory object specification
return to specifications page
This page is based on phase 59.30 (2001/05/18)
This page was translated by:Yoshiyuki.Sakakibara
Checking by:Brad Johnson