Interprocess connection question


#1

I’m about to start using the interprocess classes for an app I’m writing which has to be set up as a sever and receive messages from another app(one that wasn’t written with Juce). As the Juce demo comes with an example of interprocess communication I decided to see if the messages being sent from the client are getting through. The client connects without any issue but the messages aren’t getting through. I know the messages are being sent by the client as I can receive them with other non-juce server applications I have. Anyone have any ideas? If the messages are being sent on a particular IP address and port number shouldn’t they be coming through, just as they do when sending messages from one JuceDemo app to another?

Rory.

p.s. I’m using sockets rather than named pipes…


#2

if you’re trying to use the actual InterprocessConnection classes, it’d help to be aware that it wraps (and expects) messages with a juce-specific header [IIRC consisting of a magic number and size]. The classes are designed to make things very simple, but can only do so by assuming they’ll be present at both ends. It will only actually respond to incoming messages which have been prepared with the correct header.

If you are able to build the client app yourself, then you could probably modify it to use the same ‘juce’ message protocol (i.e. wrap the data with the correct header for InterprocessConnection).

However, if you need to use a specific message protocol, you’ll probably have to go a little lower level and use the actual StreamingSocket class directly.

Could probably do with some information to that effect in the docs, tbh!


#3

Thanks for the reply. Where can I find out about this magic header? I’m not building the client myself but I can request that it uses a particular header. In the mean time I’ll look into using the streaming socket classes. Cheers.


#4

Looking again at the interprocessConnection class constructor I see that I can set the header, by default it’s 0xf2b49e2c. If I make sure that the data being sent to my server contains that same header used when I created my connection object everything should be Ok? Is that correct?


#5

IIRC it’s a two-int header [4 bytes each]; first the magic number, then the size of the message chunk that follows.


#6

I don’t suppose anyone would have an example of a juce interprocess compliant message by any chance? I’d rather than use the lower level streaming socket class if I can avoid it…


#7

Well, it’s as I just described. First a magic number, then a size, then a stream of data (the length of which is the same as the size value preceding it in the header). There are two things to keep in mind:

1- the header ints (unsigned 32 bit, I.e. 4 bytes) must be in network byte order. So, when writing to the socket, if the platform is big endian the order will need to be swapped for each value.

2- the implementation of this message wrapping protocol is concealed in juce, and therefore subject to change should Jules see a good reason to. It’d be nice if there were some abstract functionality in InterprocessConnection to define the protocol, but there’s not much reason to when you have access to the socket class directly for more specific needs. I expect it won’t change, as it would break communication compatibility with older versions, but you never know!


#8

…you’ve got the source code right there - have a look at it! The interprocess message stuff is pretty trivial, just a couple of hundred lines of code, it should be easy to see what’s going on.