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:
udp://host:port?UdpTransport.reliable=true&UdpTransport.encrption=aes256&UdpTransport.encryptionKey=somesecretkey
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, kay.weckem...@bmw.de 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
