diff options
author | eutarass | 2009-03-04 01:58:27 +0000 |
---|---|---|
committer | eutarass | 2009-03-04 01:58:27 +0000 |
commit | 88caf8c9c877b34d651b15e963d9f666c8027fdc (patch) | |
tree | 5eaf883a57061fa05844f8c674fff4ae844edd79 /docs/TCF Specification.html | |
parent | 72723936ad2c9e203c577fa9f2645c564bdef0d3 (diff) | |
download | org.eclipse.tcf-88caf8c9c877b34d651b15e963d9f666c8027fdc.tar.gz org.eclipse.tcf-88caf8c9c877b34d651b15e963d9f666c8027fdc.tar.xz org.eclipse.tcf-88caf8c9c877b34d651b15e963d9f666c8027fdc.zip |
Implemented better handling of unrecognized commands in TCF protocol: instead of terminating a connection, peers now can send special "command is not recognized" message.
Added TCF error code "command is not recognized".
Fixed agent build error on CygWin.
Diffstat (limited to 'docs/TCF Specification.html')
-rw-r--r-- | docs/TCF Specification.html | 12 |
1 files changed, 7 insertions, 5 deletions
diff --git a/docs/TCF Specification.html b/docs/TCF Specification.html index ade4f1fe6..d86eb5791 100644 --- a/docs/TCF Specification.html +++ b/docs/TCF Specification.html @@ -540,7 +540,8 @@ string as returned by Service.getName().</p> <p>Command name interpretation depends on a service.</p> <p>A command should always be answered with result packed. Result does not have to -be positive – it can include an error code, but there always must be one. Since client +be positive – it can include an error code, or it can be special "N" result that indicates that command was not recognized, +but there always must be one. Since client cannot detect that a response is missing, if for some reasons peer is not able to answer a command, it should consider such situation a fatal communication error and it must shutdown the communication channel. It is not necessary to wait for result @@ -554,13 +555,14 @@ store the requests and time to process them.</p> <pre><b><font face="Courier New" size=2 color=#333399> <i><result></i> + ⇒ N • <i><token></i> • ⇒ R • <i><token></i> • <i><byte array: result data></i> - ⇒ P • <i><token></i> • <i><byte array: result data></i> + ⇒ P • <i><token></i> • <i><byte array: progress data></i> </font></b></pre> -<p>Result packets start with string “P” for intermediate result and “R” for final -result. Receiving of “R” result concludes execution of corresponding command. -There should be exactly one “R” result for each command. In addition, command execution can produce any number of +<p>Result packets start with string “P” for intermediate result, “R” for final +result, and “N” if command is not recognized. Receiving of “R” or “N” result concludes execution of corresponding command. +There should be exactly one “R” or “N” result for each command. In addition, command execution can produce any number of intermediate “P” results. “P” results can be sent before “R”, and it can serve, for example, as command execution progress report when execution takes long time.</p> |