On Thu, Nov 14, 2013 at 01:43:45PM +0100, Petr Pudlak 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.
Are there any actual use cases that require a blocking pipe? If so, what are they? If there aren't any relevant use cases, I'd stick with standard and simple HTTP. Probably, the sysadmins will just perform GET/POST requests using wget or curl anyway... -- Jose Antonio Lopes Ganeti Engineering 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 Steuernummer: 48/725/00206 Umsatzsteueridentifikationsnummer: DE813741370
