On Sun, Jun 1, 2014 at 8:33 PM, Marcus Ottosson <[email protected]>
wrote:
> Ah I was referring to your question above that sparked the RPC discussion
> - Tony
>
> Hmmmmmm. :) Ok, for this, let’s try and define what we mean with RPC.
> Here’s what I mean:
>
> *RPC call, where proxy represents a remote machine*
>
> # Local>>> proxy.log.info('hello world')
> # Remote>>> log.info('hello world')
>
> Here, log.info is the name of the function called on the other side. If
> the function does not exist, you get an AttributeError. There is a 1-1
> correspondence between caller and receiver. Like we would expect, from a
> local call in traditional, imperative programming languages such as Python.
>
That could be one version of an RPC function call, where the call
completely blocks on the final computed result, and the RPC implementation
translates exceptions across the wire and raises the equivalent exception
on the other side, to make it look 100% local. But it doesn't have to be
this way, and if you compare them specifically as this being the
definition, then I agree you are more limited with the RPC approach and it
does hide the fact that it is a remote call.
> Tony, when you say you’ve worked with messaging without RPC, how does
> something like that look? And Justin, how does it look for you?
>
Maybe Tony wants to give example of this, but I feel it is a redundant
question because we have both worked with zmq and know what it looks like
to send an arbitrary python object that represents a 'message' or a
'command' across the wire to be evaluated on the other end. It could go
into a queue and be picked up by workers, it could be broadcasted out to a
number of peers, and the sender could either directly wait on a reply, or
receive an async reply on another socket/channel.
> What do you guys think about this for differences?
> http://www.inspirel.com/articles/RPC_vs_Messaging.html
>
I agree with the parts about it potentially hiding remote calls to look
local, but again I feel it is an implementation detail and not the sole
definition of RPC. As I have described before, you can have an RPC call
that is very explicitly presented as being a remote call, and it can:
- Return the final computer value immediately, blocking
- Return a promise type immediately, allowing the calling to poll the
result later
- Return nothing, immediately
- Translate exceptions from the remote side to the local side, in any
format it wants. Even exceptions called RemoteException() (or not raise
exceptions)
But to me, the RPC aspect is that it presents a predefined interface. A
function with a signature. This signature is validated as part of the RPC
implementation before it goes onto the wire. I'm not really a fan either of
trying to hide and mix in RPC calls with other objects to make it
ambiguous.
> Personally I would prefer not to talk in terms of “patterns” as that
> sounds very java-minded (command pattern, actor pattern, …), and boxing you
> into thinking about what you can and cannot do. - Justin
>
> I’m not sure you’ve got the right idea here. Patterns have little to do
> with languages, nor about what you can or cannot do. A pattern, as far as I
> can tell, is a description of a scenario, coupled with pros and cons and a
> name so that we can refer to it in general conversation.
>
> Are we talking about something like this?
>
> http://www.amazon.co.uk/Design-patterns-elements-reusable-object-oriented/dp/0201633612
>
> Also, where did “patterns” enter into the discussion? Do you consider RPC
> a pattern? On the contrary, patterns can be used to implement RPCs, like
> the Proxy Pattern <http://en.wikipedia.org/wiki/Proxy_pattern> and the
> Abstract
> Factory Pattern <http://en.wikipedia.org/wiki/Abstract_factory_pattern>.
>
Yea that one. What I mean is that usually when you hear talks of "Abstract
Factory Pattern", "Command Pattern", etc, it is from people with Java
backgrounds. That is all I meant. Not that patterns are a language-specific
thing. I'm not saying you specifically mentioned patterns in this
particular conversation, but I am just pointing out that I feel it is a bit
limiting to think of the elements of this topic in concrete definitions.
i.e. "This article defines RPC as being X, and message passing as being Y,
and this is why one is better than the other". I would take it with a grain
of salt (as I am sure you are already doing by asking opinions here). My
point that I keep going back to is that I don't think RPC, to me, is
exactly and solely what you have represented in your articles. I think it
can overlap with message passing and is basically a representation of the
same message passing principles under the hood.
>
>
>
> On 31 May 2014 22:58, Justin Israel <[email protected]> wrote:
>
>>
>> On Sun, Jun 1, 2014 at 9:39 AM, Marcus Ottosson <[email protected]>
>> wrote:
>>
>>> I think both ways work great
>>>
>>> Aw, that’s no good. :) I’m looking for actual cases where one is more
>>> appropriate than the other, not which one is the silver bullet of computing.
>>>
>>> It’s a discussion on distributing work via a chat-like interface, not
>>> very generalised I’d think, but if you’d like let’s throw in some numbers:
>>>
>>> In the conversation, there’d be around:
>>>
>>> - 500 peers in total
>>> - 50 of them being active within any given second
>>> - within which 2 tasks are being distributed continually
>>> - Tasks are at the size of “hello world”, “create directory”, “list
>>> directory”, “write metadata”, “add 1 to 1” etc..
>>> - ..each taking up a maximum of 1 second each.
>>>
>>> Personally I would prefer not to talk in terms of "patterns" as that
>> sounds very java-minded (command pattern, actor pattern, ...), and boxing
>> you into thinking about what you can and cannot do. I see RPC as just a
>> formalized layer of message passing. Under the hood you have a socket
>> sending a message, and someone on the other side receiving the message, and
>> sending a reply. The difference is that RPC puts you firmly into a
>> request-reply situation, where the reply may not even be for the computed
>> answer. The reply could just be an id for which the caller could use as a
>> promise to then poll for the computed result at a later date.
>> Using a pure message passing framework like ZeroMQ, as you already know,
>> gives you the tools to implement more communication types like push-pull,
>> and pub-sub. If these types of communication are important to your
>> application, then RPC is probably not the single solution. It can
>> definitely be used for a client to talk to a server, and then a server can
>> use features of zmq to talk to workers. But in terms of the client talking
>> to the server, I would see RPC or lower level message passing being pretty
>> much the same camp. Either you are directly sending the structured message,
>> or you are using a predefined interface that will send your message based
>> on parameters. Either you want to wait for the answer or you don't.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Python Programming for Autodesk Maya" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2SdTHud6bCeipDSScTkUei-MpEz3uXJOC1AX94Z2Kadg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2SdTHud6bCeipDSScTkUei-MpEz3uXJOC1AX94Z2Kadg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> *Marcus Ottosson*
> [email protected]
>
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBmV3JA6S96nWAH-SJ2iPiwfLFQ6L-LzL%2Bjd1t8Mcc20Q%40mail.gmail.com
> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBmV3JA6S96nWAH-SJ2iPiwfLFQ6L-LzL%2Bjd1t8Mcc20Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3A0F8L9oK07snGzjkPQgsYu%2BGUBpGormTPNUu7osgc5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
