river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Discovery v3
Date Tue, 08 Jan 2013 08:02:49 GMT
That's old school mate, in uri, shemes aren't protocols, that's historical.  Schemes should
also be registered.

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:

lookup service id
member groups
sequence number.

A size limit of 512 bytes is recommended.

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

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.

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

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

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

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


----- 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.
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message