river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gregg...@gmail.com>
Subject Re: Discovery v3
Date Tue, 08 Jan 2013 17:48:42 GMT

On Jan 8, 2013, at 2:02 AM, Peter <jini@zeus.net.au> wrote:

> That's old school mate, in uri, shemes aren't protocols, that's historical.  Schemes
should also be registered.

I'm not convinced it's that "old".  It's been around for eternity, but from a practical perspective,
there's something to be said for consistency.

> 
> There's something more going on here, we need to think it over.
> 
> Lets look at how the discovery protocol works now (somewhat simplified):
> 
> Your client, using multicast discovery recieves a udp version 2 packet, it contains the
following:
> 
> Protocol version
> multicast packet type
> discovery format id
> discovery format data (bytes)
> 
> The discovery format data encompasses all data from the end of the format id to the end
of the packet and is encoded according to the discovery format indicated by the discovery
format id.  Which contains:
> 
> Host
> port
> lookup service id
> member groups
> sequence number.
> 
> A size limit of 512 bytes is recommended.

This is multicast, and I'm not worrying about multicast, it already works, what we want to
do, is something completely different which has different network characteristics such as
firewall traversal, interaction with new Java modularization, different forms of security
etc.

> 
> The client then performs unicast discovery using a tcp Socket, with the hostname and
port provided.

That's what "Jini:" specifies, yes, but that's where we are thinking about doing something
completely different than what we already have.

> 
> So far we're considering replacing the host and port with a uri string.
> 
> But there's a need also to allow custom Socket's as Sim demonstrated with disco v1 and
LookupLocator.

Custom sockets are part of the "protocol handler".   It will be pluggable at the client end,
and thus creation of the socket connectivity (or whatever it is) can be configurable in that
way.

> URL handlers aren't suitable, they only perform retrieval, we need a bi directional socket
connection.

The existing URLStreamHandler provides the ability to "create the connection" that's all.
 We just need to create a similar mechanism which provides for "stream" based I/O in both
directions.  I think that the EndPoint mechanism is the right place to look/hookup.

> It sounds like the socket provider is a separate concen from the uri string, to enable
substitution of socket providers.

Sockets should be provided in the way that the "protocol" requires.  I'm not convince that
these are separable bits.  At the most, the protocol handler should provide an API for InputStream
and OutputStream setup.  Socket is a very limiting thing.  NIO should also be part of what
happens.

> SocketAddress is an abstract class and Sockets are just endpoints for communication between
two machines.

Sockets are one type of endpoint, not the only type...

> Sockets don't need to be trusted, simplifying discovery trust issues, trust is left to
the jeri endpoint used over that socket.

This is where we need to "reconsider" what is going on.  Endpoints are a fine abstraction,
but we want to make it possible for the protocol handler to end up with the appropriate EndPoint
abstraction that supports the protocol requirements.

Gregg

> 
> Cheers,
> 
> Peter.
> 
> 
> ----- Original message -----
>> Humm, that "protocol" specifier has, in all current usages of URI/URL that I've
>> got experience with, specific transport included in the protocol.  HTTP, is an
>> application protocol, which assumes a "streaming socket" connection to TCP port
>> 80.  Other application protocols have similar details.  HTTPS is used for ssl
>> encapsulation of the "streaming socket" connection.    It imposes a different,
>> default TCP socket (443), since the actual transport negotiation, which occurs
>> up front, needs to progress differently than port 80.
>> 
>> I don't think there is any practical reason why the protocol/scheme name can't
>> be used to select a driver/stream-handler like software implementation.  The
>> protocol handler will have the scheme of the URL will it not?
>> 
>> Gregg Wonderly
>> 
>> On Jan 7, 2013, at 4:42 AM, Peter Firmstone <jini@zeus.net.au> wrote:
>> 
>>> On 7/01/2013 11:32 AM, Gregg Wonderly wrote:
>>>> I think that using  "reference" rather than a protocol string is not a good
>>>> idea, because it puts this important differentiation at the end rather than
>>>> first.  Just using
>>>> 
>>>> jini: for discovery V1 or V2
>>>> usb: for something over a USB interface of yet to be decided nature
>>>> udt: for UDT
>>>> mekong: for mekong
>>>> 
>>>> etc., would be the right choice.  For me, that would provide a better bases
>>>> for a protocol handler/driver mechanism.
>>>> 
>>>> Gregg Wonderly
>>> 
>>> I did consider that, but it clobbers dns, we loose the scheme information,
>>> making life harder if we wanted to do dns-srv discovery. (Not that you'll use
>>> dns-srv for usb, but you might for mekong or udt).
>>> 
>>> Someone using dns srv to discover udt won't know whether it's jini or
>>> something else.
>>> 
>>> You're right though, using the fragment or reference component is a hack.
>>> 
>>> We could use the path segment, it has no meaning presently for discovery,
>>> jini://.
>>> 
>>> "/" could potentially be used as a separator for nested Socket providers.
>>> 
>>> This might allow the client and server to nest Sockets in an identical
>>> hierarchy.
>>> 
>>> discovery SSL
>>>                   |
>>> DeflateSocket (compression)
>>>                   |
>>> MekongSocket
>>> 
>>> Cheers,
>>> 
>>> Peter.
>>> 
>> 
> 


Mime
View raw message