[jboss-dev] Remoting 3.0

[Tim Fox]

Ron Sigal wrote:
> I'm just trying to collect architectural requirements for now.
More requirements:

Would need ability for remoting to work over HTTP, SSL and UDP.

UDP is the unusual one here being unreliable, but is useful to us for 
fast casting of unreliable messages to topic subscribers in messaging.

>   I assume that MINA will play a big role in Remoting 3.0.
>
> Tim Fox wrote:
>> 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().
>>
>> Instead of trying to write your own, have you looked at other 
>> frameworks, which have already done the hard work? (MINA is the 
>> obvious one, there is also Grizzly but I don't know much about that).
>>
>>>
>>>> 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-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."
> ------------------------------------------------------------------------
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>