Client/server (req-rep) specification

[eile]

See latest diff for a variant of asynchronous requests. The zmq API (req-rep-dealer-router) and doc is "flexible" for this type of use cases. I hope I got it now for the impl.

[eile]

There is an apparent contradiction between "Certain operations are by necessity synchronous" and "Requirements: Asynchronous remote procedure call".

The exchange is synchronous, the API is not. Will clarify.

[eile]

If the API is asynchronous it must return a future

No, it can also take a functor which is called on completion. I picked this approach since it does not require the reply object (if any) to be passed into the get().

[eile]

I'll pick your use cases into the Examples section.

[eile]

On reading them, maybe not: 1, 2 and 3 are special cases of 4: 1) is 4 with a return value 2) is 4 with parameters and a return value 3) is 4 with parameters

[eile]

Or, to phrase it differently: The get Serializable is both your function name (the type uuid) and parameters (object data, may be empty), and the ReplyFunc is your return value. With this you can do any remote call.

[hernando]

Why not call get, request? That name doesn't imply there's a return value at all.

Using a future and a template function would allow to introduce some type safety at least in the API. Even if type-safety is not implemented initially, it could be implemented later. The future also provides a natural way of propagating exceptions from the server and allows proper handling in the client. Right now it's not clear at all how errors are handled.

[eile]

Why not call get, request? That name doesn't imply there's a return value at all.

Good idea. Will change.

[eile]

future and a template function would allow to introduce some type safety

Some, but not all. The bigger issue is that the reply object changes memory layout and we get a client-server mismatch. Since it would still be the same class, a future would not catch (ha!) this. The reply type id needs to be part of the protocol.

[hernando]

The future forces the client to tell the implementation which is the expected type, the implementation still needs some mechanism to gurantee that (which at the moment is missing). But since it also depends on changing the protocol, it's not so different from the current proposal in terms of guarantees anyway.

[eile]

The future forces the client to tell the implementation which is the expected type, the implementation still needs some mechanism to gurantee that (which at the moment is missing). But since it also depends on changing the protocol, it's not so different from the current proposal in terms of guarantees anyway.

The implementation should not care about the type, but about the type id which is a stronger guarantee and the only one used in other parts of the API. One gains exactly nothing with the template method, because even when using the concrete type it does not prevent sending another type from the server. Note that the sync API in the first iteration used get(Serializable& req, Serializable& rep).

[eile]

reply typing addressed in a1193a7

[eile]

See https://github.com/eile/ZeroEQ/tree/reqrep for WIP

[eile]

Ping: What's left to discuss here?

[eile]

I'll eventually need an approval...