On Jan 8, 2013, at 2:02 AM, Peter <[email protected]> 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 <[email protected]> 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. >>> >> >
