etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scott comer <>
Subject Re: Application protocol URI
Date Wed, 03 Nov 2010 23:51:35 GMT
well, "tcp:..." doesn't entirely mean tcp, but rather is just a 
conveniently picked name which is bound to a transport stack factory.

tls is tcp with tls stream encryption.

tcp2 is tcp as well, but with a selector scheme for managing sockets. 
tls2 is tcp2 with tls encryption.

your uri scheme is up to you, you can call it udp or something else. 
there is possibly a length limitation on schemes. and we can always 
argue about it later, so don't let it drag you down. mnemonic is ok, but 
i wouldn't go overboard. you can also use uri query terms to select options:


there are several main option groups:

    * reliability (delivery guaranty)
    * encryption
    * tamper resistance (mac)
    * session / connection management
    * authentication

anyone got any more?

mainly, both ends have to have more or less the same scheme and options 
selected. the best practice in a complex setup is to use the name 
service to abstract uris.

have fun!

scott out

On 11/3/2010 4:36 AM, wrote:
> Hi,
> an issue concerning the URI: Right now, only the transport protocol is part of the URI
(e.g. tcp:://...).
> Shouldn't there be a hint to the application protocol, e.g. etch_tcp:://...  which seems
more appropriate? The question arises e.g. with the UDP extensions, which could provide different
application semantics like "reliable_etch_udp" or "maybe_etch_udp". These protocols could
use different headers, so it could be needed to distinguish between different application
protocols in the URI.
> Best regards,
> Kay Weckemann
> BMW Group
> Research and Technology

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