1% BEGIN LICENSE BLOCK 2% Version: CMPL 1.1 3% 4% The contents of this file are subject to the Cisco-style Mozilla Public 5% License Version 1.1 (the "License"); you may not use this file except 6% in compliance with the License. You may obtain a copy of the License 7% at www.eclipse-clp.org/license. 8% 9% Software distributed under the License is distributed on an "AS IS" 10% basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See 11% the License for the specific language governing rights and limitations 12% under the License. 13% 14% The Original Code is The ECLiPSe Constraint Logic Programming System. 15% The Initial Developer of the Original Code is Cisco Systems, Inc. 16% Portions created by the Initial Developer are 17% Copyright (C) 2006 Cisco Systems, Inc. All Rights Reserved. 18% 19% Contributor(s): Kish Shen, IC-Parc 20% 21% END LICENSE BLOCK 22% 23% $Id: embremoteproto.tex,v 1.3 2015/01/14 01:31:09 jschimpf Exp $ 24% 25% Author: Kish Shen, IC-Parc 26% 27\chapter{The Remote Interface Protocol} 28\label{chapremoteproto} 29%HEVEA\cutdef[1]{section} 30 31\section{Introduction} 32 33The {\eclipse} remote interface protocol is used to build a remote 34interface between {\eclipse} and some programming language. A program 35written in that programming language can interact and communicate with a 36separate {\eclipse} process via the remote interface. The Tcl remote 37interface (chapter~\ref{chapremote}) is an example of such an 38interface. This chapter describes the protocol, so that remote interfaces 39to other programming languages can be built. 40 41The protocol is designed to allow the implementer to build an interface 42that is compatible with the embedding interface of the same language. This 43should allow the same code (in both {\eclipse} and the other language) to 44be used in both interfaces. On the {\eclipse} side, the concept of {\it 45peers\/} is used to unify the remote and embedding interfaces. 46 47Another feature of the remote interface is that on the {\eclipse} side, 48the interface is independent of the programming language that is being 49interfaced to. It should be possible to write {\eclipse} code with the 50interface (e.g.\ for a GUI) and change the remote code without needing to 51rewrite the code on the {\eclipse} side. 52 53Briefly, a socket connection is established between the remote program and 54an {\eclipse} process. The processes exchange messages in the EXDR (see 55chapter~\ref{chapexdr}) format according to the protocol. This allows the 56communication to be platform independent, and the {\eclipse} and remote 57processes can be located on any two machines which can establish socket 58connections. 59 60\section{Basics} 61\label{remoteprotobasic} 62 63The remote interface is established by {\bf attaching} the remote and 64{\eclipse} processes. The attachment establishes two socket connections 65between the two processes: 66 67\begin{description} 68\item[Control] This connection is used to control the remote 69interface. Messages (in EXDR format) are sent in both directions according 70to the remote protocol to co-ordinate the two processes. 71\item[Rpc] This is used to send {\bf ec_rpc} goals from the remote process 72to {\eclipse} and return the results. The goal is sent in EXDR format. 73\end{description} 74 75More than one remote attachment can be established in an {\eclipse} 76process. Each attachment is independent, and is a remote peer, 77identified by its control 78connection. Each remote attachment has two sides: the {\eclipse} side, and 79the remote side. 80 81At any one time, either the {\eclipse} or the remote side has {\it 82control}. When a side has control, it is able to send messages to the other 83side via the control connection. The side that does not have control 84waits for messages to arrive on the control connection. On the {\eclipse} 85side, execution is suspended while it does not have control. In general, once a 86control message is sent, the control is passed to the other side, and the 87side that sent the message waits for a reply message from the other side. 88 89The {\bf ec_rpc} mechanism is designed to be the main way for the remote 90side to interact with the {\eclipse} side. The remote side can send an 91{\eclipse} goal, in EXDR format to be executed by the {\eclipse} side. This 92can only be done while the remote side has control, and when the goal is 93issued, a message is sent via the control connection to the {\eclipse} 94side, and control is passed to the {\eclipse} side. Control is passed back 95to the remote side when {\eclipse} completes the execution of the goal. 96 97After the attachment, extra I/O connections can be established between the 98two sides. This allows data to be transferred from one side to the other. 99These connections (referred to as peer queues) can be of two types: 100 101\begin{description} 102\item[synchronous] These queues are synchronised by the control 103connection. Control messages are exchanged between the two sides to ensure 104that they are both are synchronised for the data transfer: one side 105consumes the data that is sent from the other. This ensures that no 106blocking occurs with the I/O operations across the sockets. 107 108\item[asynchronous] These queues can perform I/O operations that are not 109 co-ordinated by the control 110connection. Either side can write to or read from the queue 111without transferring control. In fact, if the remote language is 112multi-threaded, it can perform asynchronous I/O while {\eclipse} 113side has control. Note that asynchronous I/O 114operations may block on the {\eclipse} side. 115 116\end{description} 117 118\section{Attachment} 119\label{remoteattach} 120\subsection{Attachment Protocol} 121 122\begin{figure}[hbt] 123\begin{center} 124\includegraphics{remoteconnect.ps} 125\end{center} 126\caption{Summary of the attachment protocol} 127\label{rattach} 128\end{figure} 129 130 131The attachment process is summarised in Figure~\ref{remoteattach}. It is 132initiated from the {\eclipse} side, by either calling 133\bipref{remote_connect/3}{../bips/kernel/externals/remote_connect-3.html} or the more flexible \bipref{remote_connect_setup/3}{../bips/kernel/externals/remote_connect_setup-3.html} 134and \bipref{remote_connect_accept/6}{../bips/kernel/externals/remote_connect_accept-6.html} pair. In fact, {\bf remote_connect/3} is implemented using {\bf 135remote_connect_setup/3} and {\bf remote_connect_accept/6} with default 136values for some of the arguments. 137 138The attachment can be divided into several phases: 139 140\begin{enumerate} 141\item Initialisation and handshaking: the control connection is 142established, and handshaking between the two sides are carried out -- 143checking that the remote protocols on the two sides are compatible; 144checking the pass-term. 145\item Establishing the ERPC connections and exchange of information 146(remote language, {\eclipse} name for the peer). 147\item User-defined initialisations. 148\end{enumerate} 149 150The remote protocol version is stored in the flag {\tt 151remote_protocol_version}, accessible via \bipref{get_flag/2}{../bips/kernel/env/get_flag-2.html} 152as an integer version number. 153This version number should only change when the protocol is 154modified. Checking of the version ensures that the same (or at 155least compatible) versions of the protocol are used, so that the two sides 156behaves correctly. The version information is sent from the remote side 157(which must have its own copy of the version information), and the 158{\eclipse} side checks that this is compatible with the protocol version it 159is using. In order to cope with remote connections which may not be using 160the remote protocol, the {\eclipse} side waits only for a fixed period of 161time for the remote side to send the version information before timing out. 162 163Time-out on the {\eclipse} side can also occur for forming any of the 164connections between the two sides, from the control connection to the peer 165queue. This is specified by the user in {\tt remote_connect_accept/6}. If 166time-out occurs during the attachment, then the attachment process is 167abandoned, and the predicate fails (any connected sockets will be closed). 168 169The detailed sequence of events for the attachment for the remote side 170(with some description of the relevant {\eclipse} side actions) are: 171 172\begin{enumerate} 173\item {\eclipse} side: a socket server for the control connection is 174created, using the address Host/Port which can be specified by the 175user. It then waits to accept a socket stream for the control connection 176from the remote side. The user can specify the amount of time to wait 177before this operation times-out, which would then terminate the attachment. 178 179\item Remote side: create a client socket stream for the control connection, 180with an address compatible with Host/Port. The socket stream should 181be in blocking mode, and perform no translation on the data sent. 182\item Remote side: sends the remote protocol version information on the 183control socket in EXDR format and flush it. This should be a {\tt 184remote_protocol/1} term. 185\item {\eclipse} side: reads the EXDR version term from the control 186socket, and compares with the version on the {\eclipse} side. If the two 187protocols are compatible, it sends the EXDR string {\tt yes} back to 188the remote side; otherwise it sends the {\eclipse} remote protocol version 189to the remote side and disconnects from the remote side (raising 190unimplemented functionality error). The {\eclipse} side waits at 191most 100 seconds after the control connection is established for the remote side's version: after 192this the {\eclipse} side disconnects the control connection and raises out 193of range error. 194\item It is expected that the future versions of the protocol will remain 195unchanged up to this point at least, to ensure the proper handshaking and 196checking of versions. 197\item Remote side: write the `pass-term' in EXDR format on the newly created control 198connection and flush it. This provides a simple security check: {\eclipse} 199side will check if the `pass-term' matches the `pass-term' it was given 200when the remote connection was initiated -- for \bipref{remote_connect/3}{../bips/kernel/externals/remote_connect-3.html}, the 201pass-term is the empty string, but the user can specify any pass-term if 202\bipref{remote_connect_setup/3}{../bips/kernel/externals/remote_connect_setup-3.html} and \bipref{remote_connect_accept/6}{../bips/kernel/externals/remote_connect_accept-6.html} are 203used. If the terms are not identical, then the {\eclipse} side will 204discontinue the attachment process. 205 206\item Remote side: read from the control connection the {\eclipse} name for the control 207connection. This is sent in EXDR format, and is used to identify this 208particular remote attachment -- the peer name for the peer. This name is needed when calling ec_rpc goals 209that refer to the peer. 210\item Remote side: write the name of the programming language (e.g.\ tcl, java) of the 211remote process on the control connection. This should be in EXDR string 212format, and the connection flushed. 213\item {\eclipse} side: read the name of the programming language and store 214it (it can be accessed later via \bipref{peer_get_property/3}{../bips/kernel/externals/peer_get_property-3.html}). The {\eclipse} 215side now wait to accept the socket stream (using the same socket server as 216the control connection) for the ec_rpc connection. This can also time-out. 217\item Remote side: create a client socket stream for the ec_rpc connection, using the 218same Port as for the control connection. This stream should be in 219blocking mode, and perform no translation on the data sent. The server 220socket on the {\eclipse} will be closed after accepting this client. 221\item Remote side: read the control connection name again on the remote side, on the 222newly established ec_rpc connection. This is also sent in EXDR format. This 223is designed to verify that the ec_rpc connection is indeed connected to the 224{\eclipse} side. 225\item Remote side: the remote side now has control. Any user-defined initialisations on the remote 226side can now be performed, to make the remote side ready for the 227interaction. The remote side has the control initially. Note that 228user-defined initialisations on the {\eclipse} side is also performed after 229sending the control name on the ec_rpc connection. After the 230initialisation, {\eclipse} side will suspend and listen on the control 231connection for the remote side to give control back to the {\eclipse} side. 232\end{enumerate} 233 234At the end of this, the remote side should be ready for normal interaction 235with the {\eclipse} side. 236 237The remote_connect/3 or remote_connect_accept/6 predicate waits for the control to be handed back by 238the remote side before exiting. Thus when the predicate succeeds, the 239remote side has been attached and properly initialised, with {\eclipse} 240side having control. 241 242The protocol does not specify how the remote side should be informed of the 243Host/Port address for the initial socket connection. The Address can be 244fixed before hand (with the Address argument instantiated, or 245the information can be transmitted either manually or via files. In 246addition, the remote process can be started from within {\eclipse} using 247the \bipref{exec/3}{../bips/kernel/opsys/exec-3.html} command, with the host and port supplied as arguments. 248 249In accepting client socket connections from the remote side, the {\eclipse} 250side is informed of the host of the remote side. This should either be the 251client's hostname, or 'localhost'. After accepting the control connection, 252subsequent connections (for ec_rpc and any peer queues) are checked to 253ensure that they are from the same client. If not, the attachment is 254terminated by {\eclipse}. Using 'localhost' as the name on either side will 255restrict the two sides to be on the same machine (and they must both use 256localhost for Host in the address, rather than the actual hostname). 257 258\subsection{An example} 259 260The following is a simple example of making a remote attachment on the 261remote side. In this case, the remote side is also an {\eclipse} program. 262A remote attachment by a program written in another programming language 263will need to provide a similar function in that language: 264 265\begin{verbatim} 266% Example code for making a remote attachment on the remote side 267 268:- local variable(ecsidehost). 269 270% remote_attach/6 makes a remote attachment to a host ECLiPSe program. 271% Args: 272% +Host: host name on ECLiPSe side 273% +Port: port on ECLiPSe side 274% +Pass: `pass-term' - used to verify the connection 275% +Init: goal to call to perform any application specific initialisation 276% -Control: the remote side (local) name of the control connection 277% -Ec_rpc: the remote side name of the ec_rpc connection 278% -EcSideControl: the ECLiPSe side name for the control connection 279 280remote_attach(Host, Port, Pass, Init, Control, Ec_rpc, EcSideControl) :- 281 % control connection 282 new_client_socket(Host, Port, Control), 283 % send the protocol version information to the ECLiPSe side 284 % we are the remote side, so must have our own version info. 285 write_exdr(Control, remote_protocol(1)), flush(Control), 286 % read response from ECLiPSe side to make sure it is compatible... 287 read_exdr(Control, IsSameVersion), 288 (IsSameVersion == "yes" -> 289 true 290 ; 291 writeln("Incompatible versions of remote protocol. Failing...."), 292 fail 293 ), 294 % send pass-term; if this does not match the pass-term on the ECLiPSe 295 % side, it will terminate the attachment 296 write_exdr(Control, Pass), flush(Control), 297 % ECLiPSe side name for connection 298 read_exdr(Control, EcSideControl), 299 % send language name to ECLiPSe side 300 write_exdr(Control, "eclipse"), flush(Control), 301 % Ec_rpc connection 302 new_client_socket(Host, Port, Ec_rpc), 303 % read control name again on Ec_rpc to verify connection 304 % in a more sophisticated implementation, this should time-out 305 (read_exdr(Ec_rpc, EcSideControl) -> 306 true 307 ; 308 % if not verified, terminate connection 309 close(Control), close(Ec_rpc), 310 fail 311 ), 312 % Remote side now has control, call Init to perform application 313 % specific initialisations 314 call(Init), 315 % hand control over to ECLiPSe side... 316 write_exdr(Control, resume), flush(Control). 317 318 319new_client_socket(Host, Port, Socket) :- 320 socket(internet, stream, Socket), 321 connect(Socket, Host/Port). 322 323%---------------------------------------------------- 324% the following code make use of remote_attach/6 to make an attachment, 325% and then disconnect immediately when ECLiPSe side returns control 326 327test(Host, Port) :- 328 % make the remote attachment. For this simple example, there is no 329 % application specific initialisations, and the default pass-term 330 % of an empty string is used... 331 remote_attach(Host, Port, "", true, Control, Ec_rpc, _), 332 % control has been given to ECLiPSe side, 333 % wait for ECLiPSe side to return control.... 334 read_exdr(Control, _), 335 % immediately disconnect from ECLiPSe side 336 write_exdr(Control, disconnect), flush(Control), 337 % wait for ECLiPSe side to acknowledge disconnect... 338 read_exdr(Control, disconnect_yield), 339 % clean up 340 close(Control), close(Ec_rpc). 341 342\end{verbatim} 343 344In addition to the attachment, the example contains a very simple example 345of using the protocol by exchanging control messages with the {\eclipse} 346side. After attachment, it disconnects the remote attachment as soon as 347control is handed back to it. For more details on the messages, see next 348section. 349 350To try out the example, start an {\eclipse} session and initiate a remote 351attachment. This process is the {\eclipse} side: 352 353\begin{verbatim} 354(ECLiPSe side) 355[eclipse 1]: remote_connect(Host/Port, Control, _). 356Socket created at address chicken.icparc.ic.ac.uk/32436 357\end{verbatim} 358 359Now start another {\eclipse} session, compile the example program, and make 360the attachment to the {\eclipse} side: 361 362\begin{verbatim} 363(Remote side) 364[eclipse 4]: test('chicken.icparc.ic.ac.uk', 32436). 365\end{verbatim} 366 367On the {\eclipse} side, {\tt remote_connect/3} should now succeed: 368 369\begin{verbatim} 370(ECLiPSe side) 371Host = 'chicken.icparc.ic.ac.uk' 372Port = 32436 373Control = peer3 374yes. 375[eclipse 2]: 376\end{verbatim} 377 378The remote side is suspended, awaiting the {\eclipse} side to return 379control. To return control to the remote side, the {\eclipse} side should 380call \bipref{remote_yield/1}{../bips/kernel/externals/remote_yield-1.html} (see section~\ref{remotesupport} for a description 381of {\tt remote_yield/1}): 382 383\begin{verbatim} 384(ECLiPSe side) 385[eclipse 2]: remote_yield(peer3). 386Abort 387[eclipse 3]: 388\end{verbatim} 389 390In this simple example, when control is returned to remote side, it 391immediately disconnects, thus the {\tt remote_yield/1} on the {\eclipse} 392side is aborted (as disconnect was initiated from the remote side), as per 393the disconnect protocol. 394 395\begin{verbatim} 396(Remote side) 397[eclipse 4]: test('chicken.icparc.ic.ac.uk', 32436). 398 399yes. 400[eclipse 5]: 401\end{verbatim} 402 403\section{Remote Peer Queues} 404 405As discussed in section~\ref{remoteprotobasic}, peer queues can be formed 406interactively during an attachment between the two sides. The protocol 407provides for the creation and closing of these queues on both sides. 408 409The handling of data on these queues are performed by {\it data handlers}, 410routines which either provide data to the queue or consume data from the 411queue. They are triggered by the appropriate control messages, so that a 412data consumer handler would consume data arriving on a queue, and a data 413provider handler would send data onto a queue (which would be consumed on 414the other side). These data handlers can be user defined. 415 416The programmer for the remote side needs to provide the remote side of the 417interface to the peer queue. 418 419\subsection{Synchronous peer queues} 420 421The implementation of a synchronous peer queue on the {\eclipse} side is 422shown in figure~\ref{syncpeer}. There is an in-memory buffer, which is 423\begin{figure}[hbt] 424\begin{center} 425\includegraphics{syncpeer.ps} 426\end{center} 427\caption{{\eclipse} implementation of remote synchronous peer queue} 428\label{syncpeer} 429\end{figure} 430implemented as a memory queue in {\eclipse} (i.e. {\tt queue("")} option 431for \bipref{open/3}{../bips/kernel/iostream/open-3.html}). Associated with the memory queue is the actual socket 432stream to the remote side. 433The memory queue is the queue that the user sees on the {\eclipse} 434side, with name {\it Name} and a unique integer id {\it Queue}, which is 435the stream id for the memory queue. The id is used by both sides to identify 436the queue, as it is unique (a symbolic name can always be reassigned), and 437is used in the control messages. To conform to normal {\eclipse} streams, 438these queues appear uni-directional to the user, i.e. data can be either 439written to or read from the queue. The direction is {\it fromec} if the 440direction of the data is from {\eclipse} to the remote side (i.e.\ 441{\eclipse} can output to the queue), and {\it toec} 442if the direction is from the remote side to {\eclipse} (i.e.\ {\eclipse} 443can read from the queue). The user perform normal I/O operations on the 444memory queue, and the protocol ensures that the data is transferred 445correctly to the remote side without blocking. 446 447The socket stream is largely hidden from the user on the {\eclipse} side, 448with data automatically transferred between it and the buffer. The buffer 449is needed to ensure that when data is transferred between the two sides, 450the I/O operation is synchronised (the data is being read on one end of the 451socket while it is being written at the other), so no blocking will occur. 452When a side needs to initiate an I/O operation with the other side (either 453to write data to or read data from the other side via the socket stream), it must have control 454(otherwise it would not be in a position to initiate an action). Before 455performing the I/O operation, a control message is sent to the other side to 456allow it to prepare to read the data before the I/O operation is actually 457initiated. The memory queue thus serves to buffer the data before it is 458transferred to the socket stream. 459 460The socket stream must be connected to the remote side before it could be 461used. Control messages are used also to synchronise the connection of 462the socket. The protocol does not specify if a buffer is needed on the 463remote side, this depends on the facilities available in the language used 464for the remote side. 465 466For a particular synchronous queue, a data handler can only be defined on 467one side of the queue, but not both. 468 469\subsection{Asynchronous peer queues} 470 471I/O operations on these queues do not need to be controlled by the remote 472protocol, but their creation and closing is controlled by the remote 473protocol, so that the remote interface can keep track of these queues. 474These are implemented as raw socket streams on the {\eclipse} 475side, with I/O operations performed directly on the socket. The Name and 476Queue id for the stream is thus those for the {\eclipse} socket stream. It 477is the responsibility of the user to ensure that I/O operations do not 478block on these queues. They are provided to allow asynchronous transfer of 479data (e.g.\ from {\eclipse} side to the remote side without handing over 480control), and also they allow more efficient transfer of data. 481 482\section{Control Messages} 483 484These are the messages that are exchanged between the {\eclipse} and remote 485sides when the remote side is attached. The messages are sent on the 486control connection, and are in EXDR format. All arguments for the messages 487are either atoms or integers. The messages are used to 488co-ordinate and synchronise the two sides. A message should only be sent from a 489particular side when that side has control, and control is handed over 490to the other side when the message is sent. 491 492Most messages are used to initiate an {\it interaction\/} with the 493other side. That is, used to cause some action to take place on the 494other side: control is handed over, the action takes place on the other 495side, and eventually control is handed back 496when the action is completed. Control can also be explicitly handed over 497from one side to the other so that the other side can initiate 498interactions. Some additional messages can only be sent as part of an 499interaction, for exchanges of information between the two sides. Finally, 500there are messages for terminating the remote attachment. Note that 501interactions can be nested, that is, an interaction from one side can 502contain an interaction initiated from the other side. 503 504The implementer for the remote interface should provide the methods for a 505programmer to initiate the interactions from the remote side. These 506routines would send the appropriate control messages to the {\eclipse} 507side, and the messages should not be directly visible to the programmer. 508 509The usage of each message is summarised in the diagram(s) accompanying 510them. These diagrams show: 511 512\begin{itemize} 513\item time proceeds downward. The {\eclipse} side is shown on the left, 514the remote side on the right. Messages are shown as vertical arrows between 515the two sides. The direction of the arrow indicates the direction the 516message is sent. 517 518\item the context in which the message can be sent, i.e.\ the message from 519the other side that it is either expecting as a response, or that it is a 520response to. The message sequence is shown, with the message highlighted. 521 522\item any accompanying actions expected with the message. These actions are 523either sending or receiving data on some other connections between the two 524sides. These are shown as dashed arrows in the diagrams. 525 526\item whether nested interactions can take place between messages of an interaction. 527This is indicated by vertical ellipsis between the messages in 528the diagram. In such cases, the nested interaction can be initiated, and this 529interaction completed before the next message for the original interaction 530is expected. 531\end{itemize} 532 533\subsection{Messages from {\eclipse} side to remote side} 534 535 536\begin{description} 537\item[yield] this yields control to the remote side. The message is used either to 538implicitly return control to the remote side at the end of an 539interaction initiated from the remote side, or it 540is used to explicitly hand over control to the remote side. 541 542 543\begin{center} 544% use toimage to generate images for hevea - _ needs to be \_ 545\begin{toimage} 546\begin{picture}(200,70) 547\thicklines 548\put(70,52){\bf yield} 549\put(20,50){\vector(1,0){150}} 550\put(0,65){ECLiPSe} 551\put(150,65){Remote} 552\put(70,25){\shortstack{.\\.\\.\\.\\.\\.}} 553\put(20,0){\line(0,1){65}} 554\put(170,0){\line(0,1){65}} 555\end{picture} 556\begin{picture}(200,70) 557\put(40,52){rpc {\footnotesize \it (goal via rpc)}} 558\put(170,50){\vector(-1,0){150}} 559\put(20,46){\dashbox{5}(150,0){}} 560\put(20,46){\vector(-1,0){0}} 561\put(20,10){\dashbox{5}(150,0){}} 562\put(170,10){\vector(1,0){0}} 563\thicklines 564\put(40,16){{\bf yield} {\footnotesize \it (answer via rpc)}} 565\put(20,14){\vector(1,0){150}} 566\put(0,65){ECLiPSe} 567\put(150,65){Remote} 568\put(40,25){\shortstack{.\\.\\.\\.}} 569\put(20,0){\line(0,1){65}} 570\put(170,0){\line(0,1){65}} 571\put(40,0){\shortstack{.\\.}} 572\end{picture} 573\begin{picture}(210,80) 574\thicklines 575\put(40,12){{\bf yield}} 576\put(20,10){\vector(1,0){170}} 577\thinlines 578\put(20,46){\dashbox{5}(170,0){}} 579\put(20,46){\vector(-1,0){0}} 580\put(40,52){{\bf rem\_flushio(Q)} {\footnotesize \it (data via Q)}} 581\put(190,50){\vector(-1,0){170}} 582\put(0,65){ECLiPSe} 583\put(170,65){Remote} 584\put(40,25){\shortstack{.\\.\\.\\.}} 585\put(20,0){\line(0,1){65}} 586\put(190,0){\line(0,1){65}} 587\put(40,0){\shortstack{.\\.}} 588\end{picture} 589\begin{picture}(210,80) 590\thicklines 591\put(40,12){{\bf yield}} 592\put(20,10){\vector(1,0){170}} 593\thinlines 594\put(20,46){\dashbox{5}(170,0){}} 595\put(20,46){\vector(-1,0){0}} 596\put(30,52){{\bf rem\_flushio(Q,L)} {\footnotesize \it (L bytes via Q)}} 597\put(190,50){\vector(-1,0){170}} 598\put(0,65){ECLiPSe} 599\put(170,65){Remote} 600\put(40,25){\shortstack{.\\.\\.\\.}} 601\put(20,0){\line(0,1){65}} 602\put(190,0){\line(0,1){65}} 603\put(40,0){\shortstack{.\\.}} 604\end{picture} 605\begin{picture}(210,60) 606\put(40,32){queue\_close(Q)} 607\put(170,30){\vector(-1,0){150}} 608\thicklines 609\put(40,12){\bf yield} 610\put(20,10){\vector(1,0){150}} 611\put(0,45){ECLiPSe} 612\put(150,45){Remote} 613\put(20,0){\line(0,1){45}} 614\put(170,0){\line(0,1){45}} 615\put(40,0){\shortstack{.\\.}} 616\end{picture} 617\begin{picture}(200,120) 618\put(40,92){queue\_create(N,T,D,E)} 619\put(170,90){\vector(-1,0){150}} 620\put(40,77){socket\_client(P,N,T,D)} 621\put(20,75){\vector(1,0){150}} 622\put(40,62){socket\_connect(N,S)} 623\put(170,60){\vector(-1,0){150}} 624\put(40,47){socket\_accept(N,Q)} 625\put(20,45){\vector(1,0){150}} 626\put(40,32){resume} 627\put(170,30){\vector(-1,0){150}} 628\put(40,20){\shortstack{.\\.\\.}} 629\thicklines 630\put(40,12){{\bf yield}} 631\put(20,10){\vector(1,0){150}} 632\put(0,108){ECLiPSe} 633\put(150,108){Remote} 634\put(20,0){\line(0,1){105}} 635\put(170,0){\line(0,1){105}} 636\put(40,0){\shortstack{.\\.}} 637\end{picture} 638\end{toimage} 639\imageflush 640\end{center} 641 642The interaction-initiating messages from the remote side will be described 643in more detail in their own sections. 644 645\item[ec_flushio(Queue, Length)] this message is sent when output on a remote 646synchronous queue is flushed on the {\eclipse} side: 647 648\begin{center} 649\begin{toimage} 650\begin{picture}(200,70) 651\put(40,12){resume} 652\put(190,10){\vector(-1,0){170}} 653\put(20,46){\dashbox{5}(170,0){}} 654\put(190,46){\vector(1,0){0}} 655\thicklines 656\put(40,52){{\bf ec\_flushio(Q,L)} {\footnotesize \it (L bytes via Q)}} 657\put(20,50){\vector(1,0){170}} 658\put(0,65){ECLiPSe} 659\put(170,65){Remote} 660\put(40,25){\shortstack{.\\.\\.\\.}} 661\put(20,0){\line(0,1){65}} 662\put(190,0){\line(0,1){65}} 663\put(40,0){\shortstack{.\\.}} 664\end{picture} 665\end{toimage} 666\imageflush 667\end{center} 668 669Queue is the 670{\eclipse} stream number for the peer queue, and Length is the number of bytes 671that is being sent on the queue. Control is yielded to the remote 672side. The data on the queue Queue will be sent through the 673queue after sending this message on the control connection, so on receiving 674this message on the remote side, the remote side should read Length bytes from 675Queue. After processing the data, the remote side should return 676control to the {\eclipse} side via a {\bf resume} message. 677 678\item[ec_waitio(Queue)] this message is sent when {\eclipse} requests input 679from a remote synchronous queue, and the data is not available in the 680queue's buffer. 681 682\begin{center} 683\begin{toimage} 684\begin{picture}(210,100) 685\put(30,12){resume} 686\put(190,10){\vector(-1,0){170}} 687\put(30,32){yield} 688\put(20,30){\vector(1,0){170}} 689\put(20,56){\dashbox{5}(170,0){}} 690\put(20,56){\vector(-1,0){0}} 691\put(30,62){rem\_flushio(Q,L) {\footnotesize \it (L bytes via Q)}} 692\put(190,60){\vector(-1,0){170}} 693\thicklines 694\put(30,82){{\bf ec\_waitio(Q)}} 695\put(20,80){\vector(1,0){170}} 696\put(0,95){ECLiPSe} 697\put(170,95){Remote} 698\put(20,0){\line(0,1){95}} 699\put(190,0){\line(0,1){95}} 700\put(30,70){\shortstack{.\\.}} 701\put(30,40){\shortstack{.\\.\\.}} 702\put(30,20){\shortstack{.\\.}} 703\put(30,0){\shortstack{.\\.}} 704\end{picture} 705\begin{picture}(210,100) 706\put(30,12){resume} 707\put(190,10){\vector(-1,0){170}} 708\put(30,32){yield} 709\put(20,30){\vector(1,0){170}} 710\put(20,56){\dashbox{5}(170,0){}} 711\put(20,56){\vector(-1,0){0}} 712\put(30,62){rem\_flushio(Q) {\footnotesize \it (data via Q)}} 713\put(190,60){\vector(-1,0){170}} 714\thicklines 715\put(30,82){{\bf ec\_waitio(Q)}} 716\put(20,80){\vector(1,0){170}} 717\put(0,95){ECLiPSe} 718\put(170,95){Remote} 719\put(20,0){\line(0,1){95}} 720\put(190,0){\line(0,1){95}} 721\put(30,70){\shortstack{.\\.}} 722\put(30,40){\shortstack{.\\.\\.}} 723\put(30,20){\shortstack{.\\.}} 724\put(30,0){\shortstack{.\\.}} 725\end{picture} 726\end{toimage} 727\imageflush 728\end{center} 729 730This interaction is triggered when the {\eclipse} side attempts a read 731operation on the empty buffer of a peer queue. The operation is suspended, 732and control is yielded to remote side so that it can provide 733the required data. There should be a data-provider handler associated with 734the queue on the remote side. This handler should obtain the data, and send 735the data to the {\eclipse} side. The data will arrive from the remote side via a 736{\bf rem_flushio} message, which initiates a remote flushio interaction, nested 737within the {\eclipse} waitio interaction. The data arrives on the socket 738associated with the remote peer queue Queue, and is automatically copied by 739{\eclipse} into the peer queue buffer. Control is then yielded back to 740the remote side, completing the flushio interaction. The remote side then 741hands control back to {\eclipse} side by the resume message. The suspended 742read operation is resumed on the now non-empty buffer. 743 744The remote flushio interaction is described in more detail in its own 745section. The main difference between a remote flushio initiated on the 746remote side and one initiated by an {\eclipse} waitio described here is 747that there must not be a data-consumer handler on the {\eclipse} side, as 748the data is to be consumed by the suspended read operation instead. 749This is ensured in the protocol by prohibiting handlers on both sides 750of a synchronous peer queue. 751 752Note that the {\eclipse} side will also listen to the control connection 753while waiting for the data to be sent from the remote side. If a {\bf 754resume} is sent before the data arrives, this is likely caused by a 755programming error in the data provider handler, which finished without 756sending data to the {\eclipse} side. The {\eclipse} side will print a 757warning message on the warning output stream, and immediately yield 758back to the remote side. Other messages are handled as normal, recursively 759while waiting for the data to arrive -- this is mainly intended to allow 760for unexpected aborts from the remote side, although it could also be used to 761perform ec_rpc calls before the remote side sends the data. 762 763\item[socket_client(Port, Name, Type, Dir)] this requests the remote side 764to form a client socket connection for the remote peer queue Name. The 765queue is of type Type (sync or async), and direction Dir (fromec, toec for 766synchronous queues, bidirect for asynchronous queues). The client socket is 767to connect at port Port with the {\eclipse} side host name. 768 769\begin{center} 770\begin{toimage} 771\begin{picture}(200,100) 772\put(40,52){socket\_connect(N,S)} 773\put(170,50){\vector(-1,0){150}} 774\put(40,37){socket\_accept(N,Q)} 775\put(20,35){\vector(1,0){150}} 776\put(40,12){resume} 777\put(170,10){\vector(-1,0){150}} 778\put(40,15){\shortstack{.\\.\\.}} 779\put(40,0){\shortstack{.\\.\\.}} 780\thicklines 781\put(40,67){{\bf socket\_client(P,N,T,D)}} 782\put(20,65){\vector(1,0){150}} 783\put(0,88){ECLiPSe} 784\put(150,88){Remote} 785\put(20,0){\line(0,1){85}} 786\put(170,0){\line(0,1){85}} 787\end{picture} 788\end{toimage} 789\imageflush 790\end{center} 791 792The {\eclipse} side first creates a server socket for the peer queue Name. 793The port address is Port. This, along with the details of the queue is 794passed to the remote side via the {\bf socket_client} message. The remote side 795should then connect a client socket with Port as the port, and the Host 796used for the initial attachment (which is either localhost or the hostname 797of the \verb'eclipse' side) for the host. 798It should also perform any additional 799setups for the peer queue using the information sent with the message 800(typically this involves setting up book-keeping information for the queue 801on the remote side). When the remote side connection is established, it 802returns control to {\eclipse} via a {\bf socket_connect} message: 803 804\noindent 805{\bf socket_connect(Name, Status)} 806 807Name is the name of the queue, and should be the same as the Name sent by 808the socket_client message. This is used to verify that the messages refer 809to same interaction. The {\eclipse} side will raise an error and disconnect 810from the remote side if the name does not match. Status is either 811success or fail, depending on if the remote side successfully created the 812remote side of the queue or not. 813 814If Status is success, then the {\eclipse} side will complete the connection 815for the peer queue by accepting the socket connection. Since the remote end 816of the socket exists, the accept operation should succeed very 817quickly. If not, the operation will time-out, using the time-out interval 818specified when the attachment was made. The server socket is closed 819immediately after the accept operation. On successful connection, 820{\eclipse} first checks that this client's host is indeed the same as the 821one previously recorded for the remote side. If so, the 822{\eclipse} will finish creating the {\eclipse} side of the queue. If not, 823the connection is closed, and the operation is considered to have failed. 824 825If Status from the socket_connect message is fail, 826then the {\eclipse} side will clean up the preparation for the peer queue. 827 828The {\eclipse} side then returns control to the remote side via a 829{\bf socket_accept} message: 830 831\noindent 832{\bf socket_accept(Name,Queue)} 833 834Name is again the name of the queue, and Queue the stream id. If the accept 835was unsuccessful (or if Status for socket_connect was fail), then Queue 836will be the atom fail, indicating that the peer queue connection was 837unsuccessful. 838 839The remote side should then record the id Queue for later use (it is 840needed for the control messages connected with this peer queue). If instead 841fail was received, then the remote side should clean up the attempted queue 842connection. When the remote side has finished the final stage of the 843connection, control is returned to the {\eclipse} side via a {\bf resume} 844message, and the socket_client interaction completes. 845 846Note that the {\bf socket_connect} and {\bf socket_accept} messages are 847always exchanged during a socket_client interaction, even if the connection 848failed on the remote side before {\bf socket_connect} is sent. They also 849can only occur in this context. If these messages occur in any other 850occasion, an error should be raised. 851 852\item[queue_close(Queue)] this message is sent when the {\eclipse} side 853closes the peer queue with id Queue. 854 855\begin{center} 856\begin{toimage} 857\begin{picture}(200,60) 858\put(40,12){resume} 859\put(170,10){\vector(-1,0){150}} 860\thicklines 861\put(40,32){{\bf queue\_close(Q)}} 862\put(20,30){\vector(1,0){150}} 863\put(0,45){ECLiPSe} 864\put(150,45){Remote} 865\put(20,0){\line(0,1){45}} 866\put(170,0){\line(0,1){45}} 867\put(40,0){\shortstack{.\\.}} 868\end{picture} 869\end{toimage} 870\imageflush 871\end{center} 872 873The remote side should close the remote side of the peer queue Queue, and 874remove all bookkeeping information associated with it. Control should then 875be returned to {\eclipse} via a {\bf resume} message. The {\eclipse} side should 876also close the queue and remove bookkeeping information on the {\eclipse} side. 877 878\item[disconnect] this message is sent when {\eclipse} side initiates 879disconnect. 880 881\begin{center} 882\begin{toimage} 883\begin{picture}(200,60) 884\put(70,12){disconnect\_resume} 885\put(170,10){\vector(-1,0){150}} 886\thicklines 887\put(70,32){\bf disconnect} 888\put(20,30){\vector(1,0){150}} 889\put(0,45){ECLiPSe} 890\put(150,45){Remote} 891\put(20,10){\line(0,1){35}} 892\put(170,10){\line(0,1){35}} 893\end{picture} 894\end{toimage} 895\imageflush 896\end{center} 897 898Control is yielded to the remote side, which should acknowledge 899with the {\bf disconnect_resume} message. Once the {\eclipse} side receives this 900message, the connection between the two sides is considered 901terminated. The {\eclipse} side will then close all the connections (the 902control and ec_rpc connections, and any asynchronous and synchronous 903queues) to the remote side, and clean up the information associated with the 904attachment. After sending the disconnect_resume message, the remote side 905should also shutdown its end of the connection by closing all the 906connections on its side. 907 908Note that the disconnection message can be used to terminate the attachment 909from within an interaction. In such cases, the interaction(s) would not be 910completed. 911 912\item[disconnect_yield] this message is sent when {\eclipse} side receives 913a {\bf disconnect} message from the remote side, i.e.\ the remote side 914initiated disconnection. 915 916\begin{center} 917\begin{toimage} 918\begin{picture}(200,60) 919\put(50,32){disconnect} 920\put(170,30){\vector(-1,0){150}} 921\thicklines 922\put(50,12){\bf disconnect\_yield} 923\put(20,10){\vector(1,0){150}} 924\put(0,45){ECLiPSe} 925\put(150,45){Remote} 926\put(20,10){\line(0,1){35}} 927\put(170,10){\line(0,1){35}} 928\end{picture} 929\end{toimage} 930\imageflush 931\end{center} 932 933This message is sent as an acknowledgement to the 934disconnect message. Once the disconnect_yield is sent, the connection is 935considered terminated, and the {\eclipse} side will close all the 936connections and clean up. After the clean up, abort is called. This is 937done because the application on the {\eclipse} side (such as the remote 938development tools) may be deep inside some interaction loop with the remote 939side, and abort is the most general way of escaping from such a loop. It 940can be caught (see \bipref{remote_yield/1}{../bips/kernel/externals/remote_yield-1.html} in section~\ref{remotesupport}) if 941the user wants a more graceful termination. 942 943 944\end{description} 945 946\subsection{Messages from remote side to {\eclipse} side} 947 948 949\begin{description} 950 951\item[resume] this message hands over control from remote side to 952{\eclipse} side. This is used to either implicitly return control to the 953{\eclipse} side at the end of an interaction initiated from the {\eclipse} 954side, or to explicitly hand over control to the remote side. 955 956\begin{center} 957\begin{toimage} 958\begin{picture}(200,70) 959\thicklines 960\put(70,52){\bf resume} 961\put(170,50){\vector(-1,0){150}} 962\put(0,65){ECLiPSe} 963\put(150,65){Remote} 964\put(70,25){\shortstack{.\\.\\.\\.\\.\\.}} 965\put(20,0){\line(0,1){65}} 966\put(170,0){\line(0,1){65}} 967\end{picture} 968\begin{picture}(200,70) 969\put(40,52){ec\_flushio(Q,L) {\footnotesize \it (L bytes via Q)}} 970\put(20,50){\vector(1,0){170}} 971\put(20,46){\dashbox{5}(170,0){}} 972\put(190,46){\vector(1,0){0}} 973\thicklines 974\put(40,12){\bf resume} 975\put(190,10){\vector(-1,0){170}} 976\put(0,65){ECLiPSe} 977\put(170,65){Remote} 978\put(40,25){\shortstack{.\\.\\.\\.}} 979\put(20,0){\line(0,1){65}} 980\put(190,0){\line(0,1){65}} 981\put(40,0){\shortstack{.\\.}} 982\end{picture} 983\begin{picture}(210,110) 984\put(30,82){ec\_waitio(Q)} 985\put(20,80){\vector(1,0){170}} 986\put(30,32){yield} 987\put(20,30){\vector(1,0){170}} 988\put(20,56){\dashbox{5}(170,0){}} 989\put(20,56){\vector(-1,0){0}} 990\put(30,62){rem\_flushio(Q,L) {\footnotesize \it (L bytes via Q)}} 991\put(190,60){\vector(-1,0){170}} 992\thicklines 993\put(30,12){\bf resume} 994\put(190,10){\vector(-1,0){170}} 995\put(0,95){ECLiPSe} 996\put(170,95){Remote} 997\put(20,0){\line(0,1){95}} 998\put(190,0){\line(0,1){95}} 999\put(30,70){\shortstack{.\\.}} 1000\put(30,40){\shortstack{.\\.\\.}} 1001\put(30,20){\shortstack{.\\.}} 1002\put(30,0){\shortstack{.\\.}} 1003\end{picture} 1004\begin{picture}(210,110) 1005\put(190,10){\vector(-1,0){170}} 1006\put(30,82){ec\_waitio(Q)} 1007\put(30,32){yield} 1008\put(20,30){\vector(1,0){170}} 1009\put(20,56){\dashbox{5}(170,0){}} 1010\put(20,56){\vector(-1,0){0}} 1011\put(30,62){rem\_flushio(Q) {\footnotesize \it (data via Q)}} 1012\put(190,60){\vector(-1,0){170}} 1013\thicklines 1014\put(30,12){{\bf resume}} 1015\put(20,80){\vector(1,0){170}} 1016\put(0,95){ECLiPSe} 1017\put(170,95){Remote} 1018\put(20,0){\line(0,1){95}} 1019\put(190,0){\line(0,1){95}} 1020\put(30,70){\shortstack{.\\.}} 1021\put(30,40){\shortstack{.\\.\\.}} 1022\put(30,20){\shortstack{.\\.}} 1023\put(30,0){\shortstack{.\\.}} 1024\end{picture} 1025\begin{picture}(200,105) 1026\put(40,52){socket\_connect(N,S)} 1027\put(170,50){\vector(-1,0){150}} 1028\put(40,37){socket\_accept(N,Q)} 1029\put(20,35){\vector(1,0){150}} 1030\put(40,67){socket\_client(P,N,T,D)} 1031\put(20,65){\vector(1,0){150}} 1032\put(40,15){\shortstack{.\\.\\.}} 1033\put(40,0){\shortstack{.\\.\\.}} 1034\thicklines 1035\put(40,12){\bf resume} 1036\put(170,10){\vector(-1,0){150}} 1037\put(0,88){ECLiPSe} 1038\put(150,88){Remote} 1039\put(20,0){\line(0,1){85}} 1040\put(170,0){\line(0,1){85}} 1041\end{picture} 1042\begin{picture}(200,60) 1043\put(40,32){queue\_close(Q)} 1044\put(20,30){\vector(1,0){150}} 1045\thicklines 1046\put(40,12){\bf resume} 1047\put(170,10){\vector(-1,0){150}} 1048\put(0,45){ECLiPSe} 1049\put(150,45){Remote} 1050\put(20,0){\line(0,1){45}} 1051\put(170,0){\line(0,1){45}} 1052\put(40,0){\shortstack{.\\.}} 1053\end{picture} 1054\end{toimage} 1055\imageflush 1056\end{center} 1057 1058\item[rpc] this message is sent before the remote side sends an ec_rpc goal 1059on the rpc connection. 1060 1061\begin{center} 1062\begin{toimage} 1063\begin{picture}(200,70) 1064\put(40,16){yield {\footnotesize \it (answer via rpc)}} 1065\put(20,14){\vector(1,0){150}} 1066\put(20,46){\dashbox{5}(150,0){}} 1067\put(20,46){\vector(-1,0){0}} 1068\put(20,10){\dashbox{5}(150,0){}} 1069\put(170,10){\vector(1,0){0}} 1070\thicklines 1071\put(40,52){{\bf rpc} {\footnotesize \it (goal via rpc)}} 1072\put(170,50){\vector(-1,0){150}} 1073\put(0,65){ECLiPSe} 1074\put(150,65){Remote} 1075\put(40,25){\shortstack{.\\.\\.\\.}} 1076\put(20,0){\line(0,1){65}} 1077\put(170,0){\line(0,1){65}} 1078\put(40,0){\shortstack{.\\.}} 1079\end{picture} 1080\end{toimage} 1081\imageflush 1082\end{center} 1083 1084After sending the {\bf rpc} message, the remote side 1085should then send the ec_rpc goal (in EXDR format) on the rpc 1086connection. When the execution of the ec_rpc goal is finished, the 1087{\eclipse} side will yield control back to the remote side with a {\bf 1088yield} message, followed by the result of the ec_rpc execution on the rpc 1089connection (in EXDR format) -- the goal with its bindings if the execution 1090succeeded; `fail' if the goal failed; `throw' if an exception is generated. 1091 1092\item[rem_flushio(Queue)] this message is sent if the remote side wishes to 1093transfer data to the {\eclipse} side on peer queue with queue id Queue, and 1094the remote side does not know how many bytes will be sent with the operation. 1095 1096\begin{center} 1097\begin{toimage} 1098\begin{picture}(200,70) 1099\thinlines 1100\put(40,12){yield} 1101\put(20,10){\vector(1,0){170}} 1102\put(20,46){\dashbox{5}(170,0){}} 1103\put(20,46){\vector(-1,0){0}} 1104\thicklines 1105\put(40,52){{\bf rem\_flushio(Q)} {\footnotesize \it (data via Q)}} 1106\put(190,50){\vector(-1,0){170}} 1107\put(0,65){ECLiPSe} 1108\put(170,65){Remote} 1109\put(40,25){\shortstack{.\\.\\.\\.}} 1110\put(20,0){\line(0,1){65}} 1111\put(190,0){\line(0,1){65}} 1112\put(40,0){\shortstack{.\\.}} 1113\end{picture} 1114\end{toimage} 1115\imageflush 1116\end{center} 1117 1118After sending the message, control is transferred over to the {\eclipse} 1119side, and the data is sent on the socket stream. On the {\eclipse} side, if 1120the queue is a synchronous queue, then the data sent must be a single EXDR 1121term, because otherwise the {\eclipse} side would not know when the data 1122transfer is complete. The {\eclipse} side would read the data from the 1123socket stream as a single EXDR term, which is then written onto the 1124buffer. If an event handler has been associated with the peer queue, this 1125will now be invoked to consume the data from the buffer. If not (for 1126example, if the {\bf rem_flushio} was initiated by an {\bf ec_waitio} 1127message), then the data is left on the buffer to be processed later. 1128 1129The {\bf rem_flushio} message can also be used to sending data to {\eclipse} for 1130asynchronous queues as well. In this case, an event handler is directly 1131associated with the socket stream, and this event is invoked when the 1132rem_flushio message is received. The event handler goal in this case is 1133invoked with the `culprit' argument being the term {\tt rem_flushio(Queue, Len)}, 1134where Len is the atom `unknown'. It is up to the user-defined event handler 1135goal to properly read the data: since the length is unknown, the data sent 1136should have natural boundaries, e.g.\ EXDR terms, or use a mutually agreed 1137`end of data' marker. 1138 1139\item[rem_flushio(Queue, Length)] this message is sent if the remote side wishes to 1140transfer data to the {\eclipse} side on peer queue with queue id Queue, and 1141the length of data to be sent is known, and is specified in Length (the 1142number of bytes to be sent). 1143 1144\begin{center} 1145\begin{toimage} 1146\begin{picture}(200,70) 1147\thinlines 1148\put(40,12){yield} 1149\put(20,10){\vector(1,0){170}} 1150\put(20,46){\dashbox{5}(170,0){}} 1151\put(20,46){\vector(-1,0){0}} 1152\thicklines 1153\put(30,52){{\bf rem\_flushio(Q,L)} {\footnotesize \it (L bytes via Q)}} 1154\put(190,50){\vector(-1,0){170}} 1155\put(0,65){ECLiPSe} 1156\put(170,65){Remote} 1157\put(40,25){\shortstack{.\\.\\.\\.}} 1158\put(20,0){\line(0,1){65}} 1159\put(190,0){\line(0,1){65}} 1160\put(40,0){\shortstack{.\\.}} 1161\end{picture} 1162\end{toimage} 1163\imageflush 1164\end{center} 1165 1166After sending the message, control is transferred over to the {\eclipse} 1167side, and the data is sent on the socket stream. On the {\eclipse} side, if 1168the queue is a synchronous queue, then it would read Length bytes of data 1169from the socket stream and transfer the data to the queue buffer. 1170If an event handler has been associated with the peer queue, this 1171will now be invoked to consume the data from the buffer. If not (for 1172example, if the {\bf rem_flushio} was initiated by an {\bf ec_waitio} message), then 1173the data is left on the buffer to be processed later. 1174 1175In the case that the peer queue is an asynchronous queue, 1176an event handler is directly 1177associated with the socket stream, and this event is invoked when the 1178rem_flushio message is received. The event handler goal in this case is 1179invoked with the `culprit' argument being the term {\tt rem_flushio(Queue, Length)}, 1180It is up to the user-defined event handler goal to properly read the data. 1181 1182\item[queue_create(Name, Type, Dir, Event)] this message is sent when the 1183remote side wishes to initiates the creation of a new peer queue. Name is the 1184name of the peer queue, Type is its Type: sync for synchronous, async for 1185asynchronous. Dir is the data direction: fromec or toec, and Event is the 1186name of the event that will be raised for the event handler goal on the 1187{\eclipse} side, if no event is to be associated with the queue, this 1188should be the empty atom (\verb+''+). 1189 1190\begin{center} 1191\begin{toimage} 1192\begin{picture}(200,120) 1193\put(40,77){socket\_client(P,N,T,D)} 1194\put(20,75){\vector(1,0){150}} 1195\put(40,62){socket\_connect(N,S)} 1196\put(170,60){\vector(-1,0){150}} 1197\put(40,47){socket\_accept(N,Q)} 1198\put(20,45){\vector(1,0){150}} 1199\put(40,32){resume} 1200\put(170,30){\vector(-1,0){150}} 1201\put(40,20){\shortstack{.\\.\\.}} 1202\put(40,12){yield} 1203\put(20,10){\vector(1,0){150}} 1204\thicklines 1205\put(40,92){{\bf queue\_create(N,T,D,E)}} 1206\put(170,90){\vector(-1,0){150}} 1207\put(0,108){ECLiPSe} 1208\put(150,108){Remote} 1209\put(20,0){\line(0,1){105}} 1210\put(170,0){\line(0,1){105}} 1211\put(40,0){\shortstack{.\\.}} 1212\end{picture} 1213\begin{picture}(200,60) 1214\put(40,12){yield} 1215\put(20,10){\vector(1,0){150}} 1216\thicklines 1217\put(40,32){{\bf queue\_create(N,T,D,E)}} 1218\put(170,30){\vector(-1,0){150}} 1219\put(0,45){ECLiPSe} 1220\put(150,45){Remote} 1221\put(20,0){\line(0,1){45}} 1222\put(170,0){\line(0,1){45}} 1223\put(40,0){\shortstack{.\\.}} 1224\end{picture} 1225\end{toimage} 1226\imageflush 1227\end{center} 1228 1229Control is handed over to {\eclipse} side, which should then set up a new 1230server socket for connecting the socket stream for the peer queue. Once 1231this server socket is set up, the creation of the queue proceeds via a 1232socket_client interaction from the {\eclipse}, i.e. the {\eclipse} side 1233sends a {\bf socket_client} message. For more detail, see the description 1234for the socket_client message. At the end of the socket_client interaction, 1235the peer queue would be established, and {\eclipse} side has 1236control. The {\eclipse} side will yield control back to the remote side, 1237completing the queue_create interaction. 1238 1239Note that the {\bf socket_client} interaction is performed by the 1240{\eclipse} built-in \bipref{peer_queue_create/5}{../bips/kernel/externals/peer_queue_create-5.html}, this is the goal that 1241{\eclipse} calls on receiving the {\bf queue_create} message. 1242 1243If the initial creation of the socket server fails, then the {\eclipse} 1244side will not initiate a socket_client interaction. Instead, it will simple 1245yield control back to the remote side with a {\bf yield} message. In this 1246case, no peer queue is created. 1247 1248\item[queue_close(Queue)] this message is sent when the remote side 1249closes the peer queue with id Queue. 1250 1251 1252\begin{center} 1253\begin{toimage} 1254\begin{picture}(200,60) 1255\put(40,12){\bf yield} 1256\put(20,10){\vector(1,0){150}} 1257\thicklines 1258\put(40,32){queue\_close(Q)} 1259\put(170,30){\vector(-1,0){150}} 1260\put(0,45){ECLiPSe} 1261\put(150,45){Remote} 1262\put(20,0){\line(0,1){45}} 1263\put(170,0){\line(0,1){45}} 1264\put(40,0){\shortstack{.\\.}} 1265\end{picture} 1266\end{toimage} 1267\imageflush 1268\end{center} 1269 1270The {\eclipse} side should close the {\eclipse} side of the peer queue Queue, and 1271remove all bookkeeping information associated with it. Control should then 1272be returned to {\eclipse} via a {\bf yield} message. The queue should also be 1273closed on the remote side, with the bookkeeping information removed too. 1274 1275\item[disconnect] this message is sent if the remote side wishes to initiate 1276disconnection. 1277 1278\begin{center} 1279\begin{toimage} 1280\begin{picture}(200,60) 1281\put(70,12){disconnect\_yield} 1282\put(20,10){\vector(1,0){150}} 1283\thicklines 1284\put(70,32){\bf disconnect} 1285\put(170,30){\vector(-1,0){150}} 1286\put(0,45){ECLiPSe} 1287\put(150,45){Remote} 1288\put(20,10){\line(0,1){35}} 1289\put(170,10){\line(0,1){35}} 1290\end{picture} 1291\end{toimage} 1292\imageflush 1293\end{center} 1294 1295Control is handed over to the {\eclipse} side, which will 1296acknowledge with {\bf disconnect_yield} message. Once the {\eclipse} side 1297receives this message, the remote attachment between the two sides is 1298considered terminated. The remote side should now close all connections to the 1299{\eclipse} side. Concurrently, the {\eclipse} side will also close down its 1300end of the connections. 1301 1302The {\bf disconnect} message can be issued during an interaction. In such 1303cases, the interaction will be terminated early along with the attachment. 1304 1305\item[disconnect_resume] this message is sent in acknowledgement of a 1306disconnection initiated from the {\eclipse} side. 1307 1308\begin{center} 1309\begin{toimage} 1310\begin{picture}(200,60) 1311\put(50,32){disconnect} 1312\put(20,30){\vector(1,0){150}} 1313\thicklines 1314\put(50,12){\bf disconnect\_resume} 1315\put(170,10){\vector(-1,0){150}} 1316\put(0,45){ECLiPSe} 1317\put(150,45){Remote} 1318\put(20,10){\line(0,1){35}} 1319\put(170,10){\line(0,1){35}} 1320\end{picture} 1321\end{toimage} 1322\imageflush 1323\end{center} 1324 1325After sending this 1326message, the remote attachment between the two sides is considered 1327terminated. The remote side should now close all connections to the 1328{\eclipse} side. Concurrently, the {\eclipse} side will also close down its 1329end of the connections. 1330In addition, this message should be sent if the remote side has to 1331terminate the attachment while the {\eclipse} side has control. This can 1332happen if the remote process is forced to quit. This is the only case where 1333a message can be sent via the control connection on the remote side while 1334it does not have control. Once the message is sent, the remote side can 1335terminate its connection unilaterally. 1336 1337\end{description} 1338 1339\subsection{The disconnection protocol} 1340\label{disconnect} 1341 1342Under normal circumstances, the disconnection of the two sides is initiated 1343by the side that has control, by sending a {\bf disconnect} message to the 1344other side. The other side acknowledges this by responding with a {\bf 1345disconnect_yield} ({\eclipse} side) or {\bf disconnect_resume} (remote 1346side). The acknowledgement should be sent when that side is ready to 1347disconnect. Once the messages have been exchanged, both sides should be ready, 1348and can physically disconnect. The exchange of messages should ensure that 1349any asynchronous I/O between the two sides are properly terminated. 1350 1351However, under some circumstances, a side may be forced to disconnect when 1352it does not have control. For example, in the Tcl remote interface, the 1353root window for the Tcl process may be destroyed by the user. In such 1354cases, a unilateral disconnect will be performed by that side -- only the 1355second part of the normal disconnect protocol is performed by sending the 1356disconnect acknowledge message ({\bf disconnect_resume} or {\bf 1357disconnect_yield}) without being initiated by a {\bf disconnect} message. 1358 1359The {\eclipse} side checks the control connection for any unexpected 1360incoming messages before it sends an outgoing control message. If there is 1361a {\bf disconnect_resume} message, the {\eclipse} side will perform the 1362disconnection on its side. 1363 1364When the user exits normally from an {\eclipse} session, {\eclipse} will 1365disconnect from all remote attachments. This is done in {\bf sepia_end/0} 1366event handler. 1367 1368As part of the disconnection process on the {\eclipse} side, a user 1369definable event will be raised in {\eclipse}, just before the remote queues 1370are closed. This allows the user to define application specific handlers 1371for dealing with the disconnection of the remote interface (on the 1372{\eclipse} side). A similar handler should 1373probably be provided on the remote side. The event raised has the same name 1374as the control stream. The event handler for this event is initially 1375defined to be {\tt true/0} (i.e. a no-op) when the remote connection is set 1376up. The handler can then be redefined by the user, e.g. during the 1377user-defined initialisation during attachment: 1378 1379\begin{verbatim} 1380 1381 ... 1382 remote_connect(localhost/MyPort, Control, 1383 set_event_handler(Control, my_disconnect_handler/1)), 1384 ... 1385 1386 my_disconnect_handler(Remote) :- 1387 % just print out a message about the disconnection 1388 printf("Disconnected from remote attachment %w", [Remote]). 1389 1390\end{verbatim} 1391 1392 1393\section{Support for the Remote Interface} 1394\label{remotesupport} 1395 1396{\eclipse} provides the following predicates to support the remote 1397interface: 1398 1399\begin{description} 1400\item[\index{remote_connect/3}remote_connect(?Address, ?Peer, ?InitGoal)] 1401Initiates a remote attachment at address Host/Port. The predicate 1402will wait for a remote process to establish an attachment according to the 1403protocol described in section~\ref{remoteattach}. If instantiated, InitGoal 1404is called after the connection is established to perform any user defined 1405initialisation on the {\eclipse} side (this can be used for example to 1406define a disconnection handler that will be called when the two sides 1407disconnect). The predicate succeeds 1408when the attachment is successfully made and the remote side returns 1409control to the {\eclipse} side. Peer is the name of the control 1410connection, and is used to identify a particular remote peer (an 1411{\eclipse} session can have several). 1412 1413\item[\index{remote_connect_setup/3}remote_connect_setup(?Address, ?Peer, -Socket)] 1414{\tt remote_connect/2} is implemented by calls to {\tt 1415remote_connect_setup/3} and {\tt remote_connect_accept/6}. These lower 1416level predicates allow more flexibility in the implementation of the remote 1417attachment, at the cost of some increased complexity. 1418 1419The two predicates must be used together, with {\tt remote_connect_setup/3} 1420called first. The predicate creates a socket server for remote attachment 1421at host Host and port Port. {\tt Socket} will be instantiated to the name of 1422the socket server that is created. When the predicate returns, the remote process 1423can request the socket connection at Host/Port address (if the request is 1424issued before {\tt remote_connect_setup/3} is called, the server would 1425refuse the connection). The remote process will suspend waiting for the 1426request to be accepted. This will happen when {\tt remote_connect_accept/6} 1427is called. 1428 1429Splitting the attachment into two predicates enables the user to start the 1430remote program in between. This will allow the user to start the remote 1431attachment automatically by executing the remote program from within 1432{\eclipse} with an \bipref{exec/3}{../bips/kernel/opsys/exec-3.html} call. 1433 1434\item[\index{remote_connect_accept/6}remote_connect_accept(?Peer, +Socket, +TimeOut,?InitGoal,?PassTerm,-InitRes)] 1435This predicate accepts an remote attachment at the socket server Socket. 1436This predicate is called after a call to {\tt 1437remote_connect_setup/3}, with the same arguments for Peer 1438and Socket. The predicate will create the control and rpc connections 1439according to the protocol described in section~\ref{remoteattach} with a 1440remote process. {\tt Socket} will be closed if the attachment is 1441successful. 1442 1443{\tt TimeOut} specifies the amount of time (in seconds) that the predicate 1444will wait for a remote process to attempt a remote attachment. If no remote 1445attachment request is made in the specified time, the predicate will 1446fail. This time is also used for the time-outs on peer queue connections. 1447To make the predicate block indefinitely waiting for a remote 1448attachment, the atom {\tt block} can be used for {\tt TimeOut}. 1449 1450{\tt InitGoal} is used to define the optional initialisation on the 1451{\eclipse} side when the two sides are connected. InitGoal will be called 1452immediately after connection, before the two sides are allowed to 1453interact. If no initialisation is desired, then the argument can be left 1454uninstantiated. The result of executing the goal is returned in {\tt 1455InitRes}, which should be initially left uninstantiated. 1456 1457{\tt PassTerm} is the pass-term that is used to verify the 1458connection. The remote side sends a pass-term which is checked to see it is 1459identical to {\tt PassTerm}. If not, the attachment fails. 1460 1461Unimplemented functionality error is raised if the remote protocol used by 1462the remote and {\eclipse} sides are incompatible. This can happen if 1463one side is outdated (and using an outdated version of the protocol). 1464 1465\item[\index{remote_disconnect/1}remote_disconnect(+Peer)] 1466Initiates the disconnection of the remote attachment represented by 1467Peer. All connections (control, ec_rpc, synchronous and asynchronous 1468streams) will be closed. The predicate succeeds after the clean up. In 1469addition, a {\tt Control} event will be raised. 1470 1471\item[\index{remote_yield/1}remote_yield(+Peer)] 1472Explicitly yield control to the remote side Peer. Execution on 1473{\eclipse} side will be suspended until the remote side returns control to 1474{\eclipse} side. The predicate will succeed when remote side returns 1475control. The predicate will abort if the remote side initiates 1476disconnect. The abort will occur after the remote attachment is disconnected. 1477The abort can be caught to allow for more graceful exits in user 1478applications by wrapping the {\tt remote_yield/1} in a \bipref{block/3}{../bips/kernel/control/block-3.html} call. 1479 1480\item[\index{peer_queue_create/5}peer_queue_create(+Name,+Peer,+Type,+Direction,+Event)] 1481Creates a peer queue from {\eclipse}. {\tt Name} is the name for the queue, 1482and {\tt Peer} is the peer to which the queue would be connected. {\tt 1483Type} specifies if the queue is synchronous or not (atom sync or async), 1484and direction is the direction of the queue (fromec, toec for synchronous 1485queues, it is ignored for asynchronous queues), {\tt Event} is the name of 1486the event that will be raised on the {\eclipse} side. The user should 1487associate an event handler goal with Event. If no event is to be raised, 1488then the empty atom (\verb+''+) should be used. 1489 1490The predicate does not provide a way to specify a handler for the queue on 1491the peer side. This is because it is not possible to provide a generic 1492way that is independent of peer's programming language. 1493 1494\item[\index{peer_queue_close/1}peer_queue_close(+Name)] 1495Closes the peer queue Name from {\eclipse}. 1496 1497\end{description} 1498 1499%HEVEA\cutend 1500 1501 1502 1503