docs/doxygen/overviews/ipc.h

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