Am 10.02.2016 um 15:06 schrieb
serg.a.k...@gmail.com:
> Hi, its my question, now i am write from new accaunt.
> I am about RPC
>
> Remote Procedure Call - has two component
> REMOTE PROCEDURE call - application layer
> REMOTE procedure CALL - communication layer
> Router concent of communication layer, be responsible solely for
> communication, its mean: REMOTE CALL - and nothing else
>
> wamp has at its disposal all the necessary messages in order to separate
> the transport layer from the application layer, but does not use.
WAMP does indeed clearly separate the transport layer from the WAMP
protocol layer:
5.3 Transports
https://tools.ietf.org/html/draft-oberstet-hybi-tavendo-wamp-02#page-17
The value of this has paid off big time: Crossbar.io supports dozens of
transports.
> instead of trying to infringe on the transport layer, by imposing him
> the functionality of the application-level
>
> Now we have a wamp rpc system designed for the scheme the
> request\response(referred to as rpc) and request\ the distributed
> response (referred as progressive result)
> this caller disadvantaged. (callee may send progressive messages but
> caller can't)
> let me remind: wamp idealogy says, the peers a equal
Yes, you are right.
And yep, "progressive calls" is still missing (but we'll have it):
https://github.com/wamp-proto/wamp-proto/issues/167
>
> I think that
> *1 - need to separate the call from the procedure*, and it will be only
> one correct way,
> otherwise will *constantly infringe upon* the rights of callee or caller
> (let me remind: you claimed that separate the application layer from the
> communication level and focus on communication)
Sorry, I don't understand what you mean:(
> 2 - to impose equality through the crutch I described above
>
> /let me offer a variation on item 1/
> creat ENDCALL message
> difference between the ENDCALL and CANCEL messages
> ENDCALL - normal end of call life cycle, error mesage from peer is not
> expected
> CANCEL - emergency end of call life cycle, error mesage from peer is
> expected
> use call shema
There is no need for a new WAMP message. When a caller has issued a
call, and then cancels the call, there are multiple way how the router
can react regarding the callee (eg cancel the invocation, ignore
anything that might come back form the callee later, ..) - but in all
cases, the router must send a ERROR message to the original caller.
Otherwise the caller would have no clue and the outstanding call would
just sit idle within the client.
--
It might be easier for me to understand if you tried to explain your
high level _goals_ (from a use case perspective), rather than jumping
into protocol design proposals. Because then I have to reverse engineer
what you might have had in mind first;)
Cheers,
/Tobias
>
https://groups.google.com/d/msgid/crossbario/cabdb4c5-7d59-44d0-9729-f173c72df8d9%40googlegroups.com
> <
https://groups.google.com/d/msgid/crossbario/cabdb4c5-7d59-44d0-9729-f173c72df8d9%40googlegroups.com?utm_medium=email&utm_source=footer>.