On Thu, Nov 14, 2013 at 1:43 PM, Petr Pudlak <[email protected]> wrote: > > 2013/11/12 Michele Tartara <[email protected]> >> >> +A bi-directional, pipe-like communication channel will be provided. The >> instance >> +will be able to receive data from the host by a GET request at:: >> + >> + http://169.254.169.254/<version>/ganeti/pipe_in >> + >> +and to send data to the host by a POST request at:: >> + >> + http://169.254.169.254/<version>/ganeti/pipe_out >> + >> +As in a pipe, once the data are read, they will not be in the buffer >> anymore, so >> +subsequent get request to ``pipe_in`` will not return the same data >> twice. >> +Unlike a pipe, though, it will not be possible to perform blocking I/O >> +operations. > > > It'd be possible to create a "full" pipe with blocking IO using HTTP > CONNECT: http://en.wikipedia.org/wiki/HTTP_tunnel > > In this mechanism, the client asks an HTTP Proxy server to forward the TCP > connection to the desired destination using the "CONNECT" HTTP method. The > server then proceeds to make the connection on behalf of the client. Once > the connection has been established by the server, the Proxy server > continues to proxy the TCP stream to and from the client. Note that only the > initial connection request is HTTP - after that, the server simply proxies > the established TCP connection. > > > This could be also used to tunnel an arbitrary network protocol from an > instance somewhere.
This is interesting, but it looks like it needs a proxy server as the endpoint, and a specific client inside the VM. I think it would add too many layers. My suggestion of using just non-blocking read/write communication was because of it's simplicity: any web client, such as curl from the command line, would work in that setting. Thanks, Michele -- Google Germany GmbH Dienerstr. 12 80331 München Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores
