[jboss-dev] Remoting 3.0

[Ron Sigal]

Hi Tim,

Excellent.  This is just the kind of feedback I was hoping for.  We 
definitely want Remoting 3.0 to satisfy the needs of JBM.  You're our 
best critics. :-)

-Ron

Tim Fox wrote:
> Ron Sigal wrote:
>>
>>
>> Scott M Stark wrote:
>>> The main problem for me with the TowardsGreaterSymmetryInRemoting page
>>> is that its not talking about a base asynch message oriented
>>> architecture. Much of the current asymmetry's is due to the rpc 
>>> oriented
>>> api. If you flip this around to have a base asynch message view, all
>>> communication is handling of these messages. RPC with callbacks is
>>> setting up blocking message handlers. Symmetry from a higher level
>>> Client api is also not a requirement in my view. By definition a
>>> callback is an unpredictable event/out of band msg with respect to some
>>> rpc call returning a value. The use of client and server are also by
>>> definition asymmetric and map to msg senders/receivers. We need to 
>>> start
>>> from the bottom and move back up to the rpc api in order to be able to
>>> talk about what the 3.0 version of Client should look like.   
>>
>> Actually, a "base asynch message oriented architecture" was just what 
>> I was trying to get at.  While Remoting should continue to support 
>> the rpc model, the Connection.receive() and Connection.send() methods 
>> that I mentioned are intended to support asynchronous message sending 
>> and receiving.
> Does Connection.receive() block until it receives a message()?
>
> Remoting 3.0 needs to support non-blocking semantics too to cope with 
> very large numbers of connection (We can't have a thread per 
> connection blocking on receive()).
>
> What you probably need is some kind of select() functionality (see the 
> Java NIO API or unix select() and poll()) where you can register for 
> events - in this case a single (or small group of) thread(s) would 
> register for events on multiple "channels" and are woken up when an 
> evens matches the selector.
>
> You probably also want to build in support for aynchronous IO via 
> callbacks - in this case, you don't even have thread(s) waiting on 
> select() but register some kind of callback handler and the OS calls 
> your handler directly - this can occur with less context switching 
> than select().
>
>> Also, while it's true that client and server roles are inherently 
>> asymmetric, actors can play multiple roles (like Peter Sellers).  In 
>> Remoting, for example, callbacks (in push mode) are handled by 
>> clients on the server side talking to servers on the client side.  I 
>> think the same thing would be conceptually simpler with a 
>> "connection" abstraction that mirrors a real TCP connection: it's 
>> true that there are client and server sockets, but once the 
>> connection has been created, there can be senders and receivers on 
>> both sides.
>>
>>> The architecture also needs to be layered such that you can plug into
>>> low level message creation for the case of needing to control the on 
>>> the
>>> wire format of these messages.
>>>
>>> We are brining on the MINA lead, Trustin Lee, so we will need to 
>>> look at
>>> how
>>>
>>>   
>>
>> The idea of stacks of marshallers and unmarshallers in Remoting has 
>> been floating around for a while, and Tom did some initial work in 
>> that direction.  I'm thinking that's where the layered message 
>> handling will live.  I've been meaning to write a second document on 
>> the subject, but, in fact, MINA has a pretty flexible and 
>> sophisticated framework for chains of message handlers, which looks 
>> like a good match for what we want.  As you say, we need to 
>> understand how MINA and Remoting will work together.
>>
>>> Anil Saldhana wrote:
>>>  
>>>> Ron,
>>>>  Most of it may already be present.
>>>>
>>>> Here is what I am thinking:
>>>> a) Pluggable mechanism to do authentication at either ends of the 
>>>> pipes
>>>> (SASL)
>>>> b) Pluggable ways to secure the payload that passes through the pipes.
>>>>
>>>> Regards,
>>>> Anil
>>>>
>>>> Ron Sigal wrote:
>>>>    
>>>>> There have been various attempts to get some discussion going about
>>>>> the features desired for the next generation of Remoting, and so 
>>>>> far I
>>>>> think the buzz has broken the -80 db level.  I'm trying again with 
>>>>> the
>>>>> wiki page at
>>>>> http://wiki.jboss.org/wiki/Wiki.jsp?page=TowardsGreaterSymmetryInRemoting. 
>>>>> We in the Remoting group (i.e., me in the Remoting group) would like
>>>>> to hear from the Remoting stakeholders about what features would make
>>>>> Remoting more usable for you.  Of course, I could just go ahead and
>>>>> write fun stuff.  :-)
>>>>>
>>>>> -Ron
>>>>>       
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>     
>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>   
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development

-- 
JBoss, a Division of Red Hat
"My company's smarter than your company."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-development/attachments/20070618/d587340f/attachment.html