docs/doxygen/overviews/ipc.h

   1 /////////////////////////////////////////////////////////////////////////////
   2 // Name:        ipc.h
   3 // Purpose:     topic overview
   4 // Author:      wxWidgets team
   5 // RCS-ID:      $Id$
   6 // Licence:     wxWindows licence
   7 /////////////////////////////////////////////////////////////////////////////
   8
   9 /**
  10
  11 @page overview_ipc Interprocess Communication
  12
  13 @tableofcontents
  14
  15 wxWidgets has a number of different classes to help with interprocess
  16 communication and network programming. This section only discusses one family
  17 of classes -- the DDE-like protocol -- but here's a list of other useful
  18 classes:
  19
  20 @li wxSocketEvent, wxSocketBase, wxSocketClient, wxSocketServer - Classes for
  21     the low-level TCP/IP API.
  22 @li wxProtocol, wxURL, wxFTP, wxHTTP - Classes for programming popular
  23     Internet protocols.
  24
  25 wxWidgets' DDE-like protocol is a high-level protocol based on Windows DDE.
  26 There are two implementations of this DDE-like protocol: one using real DDE
  27 running on Windows only, and another using TCP/IP (sockets) that runs on most
  28 platforms. Since the API and virtually all of the behaviour is the same apart
  29 from the names of the classes, you should find it easy to switch between the
  30 two implementations.
  31
  32 Notice that by including @c @<wx/ipc.h@> you may define convenient synonyms for
  33 the IPC classes: wxServer for either wxDDEServer or wxTCPServer depending on
  34 whether DDE-based or socket-based implementation is used and the same thing for
  35 wxClient and wxConnection.
  36
  37 By default, the DDE implementation is used under Windows. DDE works within one
  38 computer only. If you want to use IPC between different workstations you should
  39 define @c wxUSE_DDE_FOR_IPC as 0 before including this header -- this will
  40 force using TCP/IP implementation even under Windows.
  41
  42 The following description refers to wxWidgets, but remember that the equivalent
  43 wxTCP* and wxDDE* classes can be used in much the same way.
  44
  45 Three classes are central to the DDE-like API:
  46
  47 @li wxClient - This represents the client application, and is used only within
  48     a client program.
  49 @li wxServer - This represents the server application, and is used only within
  50     a server program.
  51 @li wxConnection - This represents the connection from the client to the
  52     server. Both the client and the server use an instance of this class, one
  53     per connection. Most DDE transactions operate on this object.
  54
  55 Messages between applications are usually identified by three variables:
  56 connection object, topic name and item name.  A data string is a fourth element
  57 of some messages. To create a connection (a conversation in Windows parlance),
  58 the client application uses wxClient::MakeConnection to send a message to the
  59 server object, with a string service name to identify the server and a topic
  60 name to identify the topic for the duration of the connection. Under Unix, the
  61 service name may be either an integer port identifier in which case an Internet
  62 domain socket will be used for the communications or a valid file name (which
  63 shouldn't exist and will be deleted afterwards) in which case a Unix domain
  64 socket is created.
  65
  66 <b>SECURITY NOTE:</b> Using Internet domain sockets is extremely insecure for
  67 IPC as there is absolutely no access control for them, use Unix domain sockets
  68 whenever possible!
  69
  70 The server then responds and either vetoes the connection or allows it. If
  71 allowed, both the server and client objects create wxConnection objects which
  72 persist until the connection is closed. The connection object is then used for
  73 sending and receiving subsequent messages between client and server -
  74 overriding virtual functions in your class derived from wxConnection allows you
  75 to handle the DDE messages.
  76
  77 To create a working server, the programmer must:
  78
  79 @li Derive a class from wxConnection, providing handlers for various messages
  80     sent to the server side of a wxConnection (e.g. OnExecute, OnRequest,
  81     OnPoke). Only the handlers actually required by the application need to be
  82     overridden.
  83 @li Derive a class from wxServer, overriding OnAcceptConnection to accept or
  84     reject a connection on the basis of the topic argument. This member must
  85     create and return an instance of the derived connection class if the
  86     connection is accepted.
  87 @li Create an instance of your server object and call Create to activate it,
  88     giving it a service name.
  89
  90 To create a working client, the programmer must:
  91
  92 @li Derive a class from wxConnection, providing handlers for various messages
  93     sent to the client side of a wxConnection (e.g. OnAdvise). Only the
  94     handlers actually required by the application need to be overridden.
  95 @li Derive a class from wxClient, overriding OnMakeConnection to create and
  96     return an instance of the derived connection class.
  97 @li Create an instance of your client object.
  98 @li When appropriate, create a new connection using wxClient::MakeConnection,
  99     with arguments host name (processed in Unix only, use 'localhost' for local
 100     computer), service name, and topic name for this connection. The client
 101     object will call OnMakeConnection to create a connection object of the
 102     derived class if the connection is successful.
 103 @li Use the wxConnection member functions to send messages to the server.
 104
 105
 106 @section overview_ipc_datatransfer Data Transfer
 107
 108 These are the ways that data can be transferred from one application to
 109 another. These are methods of wxConnection.
 110
 111 @li <b>Execute:</b> the client calls the server with a data string representing
 112     a command to be executed. This succeeds or fails, depending on the server's
 113     willingness to answer. If the client wants to find the result of the
 114     Execute command other than success or failure, it has to explicitly call
 115     Request.
 116 @li <b>Request:</b> the client asks the server for a particular data string
 117     associated with a given item string. If the server is unwilling to reply,
 118     the return value is @NULL. Otherwise, the return value is a string
 119     (actually a pointer to the connection buffer, so it should not be
 120     deallocated by the application).
 121 @li <b>Poke:</b> The client sends a data string associated with an item string
 122     directly to the server. This succeeds or fails.
 123 @li <b>Advise:</b> The client asks to be advised of any change in data
 124     associated with a particular item. If the server agrees, the server will
 125     send an OnAdvise message to the client along with the item and data.
 126
 127 The default data type is wxCF_TEXT (ASCII text), and the default data size is
 128 the length of the null-terminated string. Windows-specific data types could
 129 also be used on the PC.
 130
 131
 132 @section overview_ipc_examples Examples
 133
 134 See the sample programs @e server and @e client in the IPC samples directory.
 135 Run the server, then the client. This demonstrates using the Execute, Request,
 136 and Poke commands from the client, together with an Advise loop: selecting an
 137 item in the server list box causes that item to be highlighted in the client
 138 list box.
 139
 140
 141 @section overview_ipc_dde More DDE Details
 142
 143 A wxClient object initiates the client part of a client-server DDE-like
 144 (Dynamic Data Exchange) conversation (available in both Windows and Unix).
 145
 146 To create a client which can communicate with a suitable server, you need to
 147 derive a class from wxConnection and another from wxClient. The custom
 148 wxConnection class will receive communications in a 'conversation' with a
 149 server.  and the custom wxServer is required so that a user-overridden
 150 wxClient::OnMakeConnection member can return a wxConnection of the required
 151 class, when a connection is made.
 152
 153 For example:
 154
 155 @code
 156 class MyConnection: public wxConnection
 157 {
 158 public:
 159     MyConnection(void)::wxConnection() { }
 160     ~MyConnection(void) { }
 161
 162     bool OnAdvise(const wxString& topic, const wxString& item, char *data,
 163                   int size, wxIPCFormat format)
 164     {
 165         wxMessageBox(topic, data);
 166     }
 167 };
 168
 169 class MyClient: public wxClient
 170 {
 171 public:
 172     MyClient(void) { }
 173
 174     wxConnectionBase* OnMakeConnection(void)
 175     {
 176         return new MyConnection;
 177     }
 178 };
 179 @endcode
 180
 181 Here, @e MyConnection will respond to OnAdvise messages sent by the server by
 182 displaying a message box.
 183
 184 When the client application starts, it must create an instance of the derived
 185 wxClient. In the following, command line arguments are used to pass the host
 186 name (the name of the machine the server is running on) and the server name
 187 (identifying the server process). Calling wxClient::MakeConnection implicitly
 188 creates an instance of @e MyConnection if the request for a connection is
 189 accepted, and the client then requests an @e Advise loop from the server (an
 190 Advise loop is where the server calls the client when data has changed).
 191
 192 @code
 193 wxString server = "4242";
 194 wxString hostName;
 195 wxGetHostName(hostName);
 196
 197 // Create a new client
 198 MyClient *client = new MyClient;
 199 connection = (MyConnection *)client->MakeConnection(hostName, server, "IPC TEST");
 200
 201 if (!connection)
 202 {
 203     wxMessageBox("Failed to make connection to server", "Client Demo Error");
 204     return NULL;
 205 }
 206
 207 connection->StartAdvise("Item");
 208 @endcode
 209
 210 */