InterProcessConnectionServer usage


#1

Maybe I’m just a bit slow today, but for the life of me I can’t figure out how the InterprocessConnectionServer class is intended to be used. I’ve derived my own class from it and implemented the createConnectionObject method. I can’t figure out how to get the InterprocessConnection I return AFTER its been initialized with a connected socket, which is performed after createConnectionObject returns control back to the base class. I don’t see a way to get notified that the connection is complete and ready to send data. Has anyone actually used this bad boy?


OS specific functions?
#2

sounds like your trying to tightly couple the server and the socket classes.

Your server class is just a factory class that spits out connection instances when a remote host makes a connection.

The implementation of the InterProcessConnection descendant that your server creates should stand alone from the server itself.

Essentially, what this means is that you’ll have one or more implementations of InterProcessConnection, each of which is perfectly capable of having a complete conversation with other IPCs of the same or alternate kinds. Additionally, you’ll have one lightweight IPCServer class that facilitates making the initial introduction between two IPCs that wish to talk.

In other words, don’t think about the IPCServer, rather, concentrate on making the IPC class(es) capable of communicating with a network peer, and also with the host application. Then, when you have your networking logic sussed, just create an IPCServer that knows how to instantiate one of your IPCs and register any callbacks it might offer.


#3

Thanks. That all makes sense, but I guess I need to be clearer about the issue. Given the public methods of the InterprocessConnectionServer class, I don’t see a way to get the created connections back. The only method that returns a connection is protected and doesn’t return connections in a usable state. How would a client aqcuire a new connection once its initialized?


#4

when you say client, do you mean that in the network sense? The client doesn’t use IPCServer at all.

Application 1 (the server side) :


/** Simple repeater class that sends received text to an action listener. */
class MyIPC : public InterprocessConnection, ActionBroadcaster 
{
public:
..

  virtual void messageReceived (const MemoryBlock &message)
  {
    // just relay the message on.
    sendActionMessage(message.toString())
  }

};


/** IPCServer just creates a MyIPC instance. 

     Obviously it'd be extremely easy to leave actionListener 
     dangling, so this is purely demo code.
*/
class MyIPCServer : public InterprocessConnectionServer
{
public:
  
  MyIPCServer(ActionListener* actionListener)
  :
    _actionListener(actionListener)  
  ()

protected:

  virtual InterprocessConnection* createConnectionObject()
  {
     MyIPC* ipc = new MyIPC();
     if (_actionListener != 0)
       ipc->addActionListener(_actionListener);
     return ipc;
  }
 
private:

  ActionListener* _actionListener;
};

Application 2 (the client side) :


class SimpleIPCSender : public InterprocessConnection
{
public:
..

  virtual void messageReceived(const MemoryBlock &message)
  {
    // nothing here since this example is uni-directional.
  }

};



// The main code to actually send a message:

SimpleIPCSender sender;
if (sender.connectToSocket ("127.0.0.1", 10000, 5000))
{
  String s("hello world");
  sender.sendMessage(MemoryBlock(s.toUTF8() , s.length())
  sender.disconnect()
}

(untested, and unsafe code, obviously).

Your server side IPC can get data to the host application in a number of ways. Action and Change events are ugly, but serviceable. A custom event interface for your IPC class is one, better approach. You could also, in many cases, just have the IPC class handle all of the logic involved with the communication - that’ll depend on what you’re doing.


#5

Dang overloaded syntax! I’ve obviously mislead you. By “client” I meant the guy who’s monitoring the IPC server, waiting for it to spew out connections. The network client is irrelevant.

I think you’ve confirmed what I suspected I might need though. I assumed that InterprocessConnectionServer would have a built-in notification mechanism to tell me when a new connection is available, but it appears that I need to implement that myself as you’ve done. Looks like I’d still have to wait for the “Connected” event on the connection itself since the socket isn’t actually intialized until later.

Jules, IMO, it might be nice to have this in the library, automatically notifying a listener on the message thread once the connection is created AND initialized. My $.02 (not sure what that is in British pounds).