I'm thinking that a blocking call would be an ordinary call that subsequently continuously reads from the receive-channel and checks if the id matches, returns if it does, and puts the value back on the channel otherwise. In a blocking call, you are always locked to the performance of the server. The benefit here is that all you know about your server is that it is something sitting on the other side of your channel. With ZeroMQ, it might be a router that delivers your request to the machine it thinks is most likely to be able to handle the request. The system serving your requests could be a single process executing blocking calls to a third-party http rest api, or it could be a network of load-balancing machines.
There would be no intent to solve the messenger problem explicitly -- those semantics are up to the user. By default, in the case of server death, the client side will just no longer receive responses on its receive-channel. In the case of a blocking call, this means that the client side will hang. It might be possible to have configurable semantics schemes included with the library -- This isn't an area I'm well-versed in, but maybe someone else could help explore that? Also, sometimes, your transport provider may be able to provide promises like delivery assurances (like Rabbit). There would be nothing to prevent a transport provider from enforcing its own semantics. In what ways are procedure calls different from data? It feels like a procedure call is just a data contract. This library would be doing the job of wrapping up two different queues -- one for outbound requests and one for inbound responses. It's true that you'd much rather only have the outbound queue, but sometimes you need both. -ToBeReplaced On Thursday, August 1, 2013 11:49:16 AM UTC-4, tbc++ wrote: > > How would a blocking call be created? How would you implement this in a > way that wouldn't lock one machine to another machine's performance. For > quite some time now, RPC has been considered a very bad idea since it mixes > reliable and unreliable semantics. > > With a network you're never actually sure that a message will arrive (see > the messenger problem). And yet one expects procedure calls to be reliable. > So what happens when you make a RPC call, and then the remote server dies? > What are the semantics on the sender side? > > Secondly, RPC kind of flies in the face of Clojure in general. Sending > procedure calls? Why not send data? > > I've been thinking about this a lot recently, and how the entire process > can be made to be lock safe. That is, when a remote server dies, the system > continues to respond as normal (see Joe Armstrong's thesis). I'm not > completely convinced that the CSP style works well in this context, and > that instead we should perhaps model these systems after unreliable message > passing, as that's really all that you are promised by the network protocol > anyways. > > Timothy Baldridge > > > On Thu, Aug 1, 2013 at 9:32 AM, <tobere...@gmail.com <javascript:>> wrote: > >> With core.async, cljzmq <https://github.com/zeromq/cljzmq>, and now >> zmq-async <https://github.com/lynaghk/zmq-async>, there's an opportunity >> to link RPC to channels and be free of the underlying transport system. >> I'm proposing an RPC library that sends and receives data over channels. >> >> The idea is to have a two-way communication context as a map with a >> send-channel, receive-channel, serializer, and deserializer. The user >> would be responsible for the transport mechanism between the "client" and >> the "server". >> >> When a user makes a request, the library would create a map to follow the >> JSON-RPC <http://www.jsonrpc.org/specification> and attach a UUID to it >> then send it down the send-channel. This UUID could be used in conjunction >> with pulling items off of the receive-channel to handle responses. >> >> The data flow would be: >> user-request -> wrap-in-specification -> client-serializer -> >> client-send-channel -> transport-provider -> server deserializer -> >> server-receive-channel -> user-function -> server-serializer -> >> server-send-channel -> transport-provider -> client-deserializer -> >> unwrap-specification -> client-receive-channel -> user-response-handling. >> >> The library would be responsible for wrapping the requests and responses >> according to the specification, but not the serialization mechanism nor the >> transport, since those could be very different depending on the problem. >> Utilities could be provided for a "blocking call" and managing cycling >> through responses on the receive-channel in order to find a specific >> response that has not yet been processed. >> >> As an example, the above workflow should be able to work seamlessly with >> the channels provided by zmq-async. The send-channels provided would be >> used as is, and the receive-channels would be used with an additional >> channel outside of it to take the responses off and deserialize them before >> returning to the user. The transport provider, of course, would be ZeroMQ. >> >> Are there any projects already doing this? Would people be interested? >> Any feedback? >> >> -ToBeReplaced >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com<javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
