XPC for realtime

You may be overcomplicating it.

The app can include the network code, and handle any errors that arise.
(No need for any crashes!)

Splitting your app up into separate processes is a fine approach from both a security and reliability perspective, and an XPC Service is one of the easiest ways to do that.

The OS will not terminate an XPC Service with an open transaction [1]. You can maintain an open transaction in two ways:

• If the client issues a request with a reply block, XPC keeps a transaction open until the XPC Service calls that reply block.

• The service can explicitly begin and end a transaction using xpc_transaction_begin and xpc_transaction_end [2].

In your case I think the first approach works best. Structure your XPC protocol so that the client issues a “get me the latest” request to the service, and the service responds to that request when there’s an update. That keeps a transaction open and thus prevents the system from terminating the service.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] That’s not strictly speaking true. If you put the OS under sufficient memory pressure, it will start terminating user processes, even GUI apps. However, I think it’s fair to not worry about that, because it could just as easily terminate your main app!

[2] These methods are deprecated because the replacement routines are not public (r. 29096039)-: Until that changes, it’s fine to continue using them.

is there is a way to create a XPC there is 1 request, multiple responses?

Yes. Well, technically no, because XPC is request/response based, so there can only be one response per se. However, XPC supports ‘one way’ messages, and you can use that to achieve this goal.

Exactly how you do that depends on the API you’re using (C vs NSXPCConnection), the semantics of your protocol, and design decisions that you have to make for yourself. If you care to share some details, I can elaborate.

One specific gotcha to watch out for is unbounded messaging from the server to the client. If you send a bunch of one-way messages from the server to the client and the client stops responding, the messages build up in the server’s memory. It’s possible that this could cause the server to run out of memory, which would be Bad™. There are various ways to fix this but a good option is a barrier, for example, using -[NSXPCConnection scheduleSendBarrierBlock:].

Oh, and if your overall goal here is simply to send progress updates to the client, you can use NSProgress for that.

or can I make a request and reply it only when the app/service is closed?

I don’t understand this.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks Eskimo

Exactly how you do that depends on the API you’re using (C vs NSXPCConnection), the semantics of your protocol, and design decisions that you have to make for yourself. If you care to share some details, I can elaborate.

I was goin for a NSXPCConnection, but this can be changed, the semantic is simple, the XPC Service will connect to network and receive updates over time with a bunch of simple data encoded, best bid price (double), best ask price (double), and reference. The idea is that when the service establish a websocket connection receive the data, decoded, and then send it to the main app as soon as he can, the data is not a batch, will have several updates over time.

or can I make a request and reply it only when the app/service is closed?

I mean, can I start the Service with a request, and forget about it until an error or connection is received? i don't now if there is a max time for a response, if there isn't, I can start the service, keep the transaction open until I receive a fatal message o when the service can be disconnected?

Thanks in advance

I was goin for a NSXPCConnection

That’s fine. In my experience it’s much nicer than the C API (-:

the semantic is simple, the XPC Service will connect to network and receive updates over time with a bunch of simple data encoded

OK. There are two approaches you can take here:

• You can use a single connection and configure it for bi-directional messaging, that is, decide on a new protocol for server to client messaging, set that in remoteObjectInterface on the server, and create an object that conforms to that protocol as exportedObject on the client.

• Use the reverse connection approach discussed in this thread.

Either way, the service should protect itself from a client that stops responding, as mentioned in my post above.

I mean, can I start the Service with a request, and forget about it until an error or connection is received?

In this scenario the XPC Service is tightly bound to your app. It’s fine to start a request and leave it unanswered indefinitely. The pending transaction tells the system to not stop your service. Oh, except when your app quits, where the system will stop the service always.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"