[nanomsg] different protocols, parameters

  • From: Garrett D'Amore <garrett@xxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Tue, 11 Mar 2014 09:20:53 -0700

So I’m looking at the actual effort to implement tls and websocket (each 
independently).  The coding aspect is actually pretty darn easy in my 
implementation.

There is an API semantic question though.

When constructing either a tls or a websocket connection (be it via accept() or 
connect() — or their analogs), we need a little more information than just a 
file descriptor, and more than normally fits in a URI style string.

For websocket, I need to pass a subprotocol string.   These generally get 
translated into HTTP headers.  One could imagine that we could use 
“SP.nanomsg.org” or something, but that precludes running different application 
layer protocols above.  What would be better would be to have e.g. 
“myApp.damore.org” as the subprotocol, which uses SP inside a websocket for its 
protocol.

For TLS, we need rich configuration parameters (certificates, supported 
algorithms, crypto policies, etc.)

I see several ways to do this from an API point of view (three in the case of 
websocket):

a) create a different kind of “constructor” — so that you’d have not just 
socket(), but “socket_websocket()” or socket_tls(), or somesuch.  While this 
feels natural in Go, it feels contrived in C.  I don’t like it so much.

b) create new variants of connect() and accept() that are specific to different 
protocols, e.g. connect_websocket(const char *url, const char *subprotocol), 
connect_tls(const char *address, tls_config_t *), etc.   At some level this 
feels the most natural.

c) create new socket options, for passing these parameters.  These are the 
closest fit to existing practice, but it gets muddier if you want to support 
different options for different underlying connection paths.   And as the 
options get richer, e.g. TLS configuration, we’re not talking about just simple 
integers anymore.

d) in the case of websocket (and maybe even others), we could “embed” some of 
this into the address string.  It gets pretty messy though if you want to 
support arbitrary URIs for websockets.  E.g. 
‘ws://server:port/somekind_of_path:myApp.damore.org'.   And its not clear if 
colons are going to be a problem in these paths.  If you extend this to TLS 
configuration, the address string would become messy indeed.

I’d like to know what folks think of these.  I’m leaning towards option “c” 
myself.  It isn’t strictly true that my implementation needs to follow whatever 
path the reference nanomsg implementation is going to do, but I think it leads 
to less confusion if there is similarity in the APIs when reasonable.

Btw, it should also be relatively trivial (again in Go, where we have nice API 
support) to create a nanomsg transport on top of HTTP, where each message is an 
HTTP exchange.  In that case, we’d have just normal http: and https: URIs as 
our addresses.  Its not clear to me that there would be any advantages to this 
over websocket though.  (I guess you could implement a trivial “REP” server as 
a CGI script or something.  Not sure how useful that would be though.  It might 
lower the bar for implementers to create a presence that can then plug into a 
much richer messaging ecosystem — almost anyone can write a CGI script after 
all. :-)

-- 
Garrett D'Amore
Sent with Airmail

Other related posts:

  1. Home
  2. nanomsg
  3. Archive
  4. 03-2014