how to create a http server with an accepted connection supplied by xinetd as os.Stdin

[Ted Toth]

Since I'm configuring my xinetd service with "wait=no" xinetd accepts the connection and dup's the socket fd to my go processes stdin.  I'd like to see a http.ServeConn function that takes a net.Conn argument. I can create a Conn using FileConn(os.Stdin) but I don't see anyway to use that connection to create a http server does anyone know how to do this? Maybe I could use ServerConn somehow?

Ted

[Giulio Iotti]

On Wednesday, September 16, 2015 at 10:39:07 PM UTC+3, Ted Toth wrote:

Since I'm configuring my xinetd service with "wait=no" xinetd accepts the connection and dup's the socket fd to my go processes stdin.  I'd like to see a http.ServeConn function that takes a net.Conn argument. I can create a Conn using FileConn(os.Stdin) but I don't see anyway to use that connection to create a http server does anyone know how to do this? Maybe I could use ServerConn somehow?

net.Conn is an interface. How about implementing it for a io.Reader?

Read -> from os.Stdin

Write -> to os.Stdout

Close -> close both if you want

LocalAddr -> stub, not sure how it works in inetd

RemoteAddr -> stub, not sure hot it works in inetd

SetDeadline ->  stub, too hard to do

SetReadDeadline -> stub, too hard/lazy to do

SetWriteDeafline -> stub, too hard to do

And can use the connection with http.Serve(net.Listener). You might need to stub out a listener too that returns your connection.

If I have some time I'll try this out. If you're faster, let us know!

-- 

Giulio Iotti

[Matt Harden]

Giulio, net.FileConn(os.Stdin) already gives Ted the net.Conn he needs. It's the stubbed listener that's required.

Something like this http://play.golang.org/p/88kWXkdZR7 might do it.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ted Toth]

Thanks I'll play with it and report back.

[Giulio Iotti]

On Thursday, September 17, 2015 at 12:45:54 AM UTC+3, Matt Harden wrote:

Giulio, net.FileConn(os.Stdin) already gives Ted the net.Conn he needs. It's the stubbed listener that's required.

Thanks Matt, I had the feeling it was so.

What confuses me, it's how can FileConn know it must get incoming data from one file (os.Stdin) but send on another (os.Stdout). Care to explain?

-- 

Giulio Iotti 

[Ian Lance Taylor]

It can't. But we're talking about invoking the program via xinetd
here, and xinetd will pass the same connection as file descriptors 0,
1, and 2.

Ian

[Matt Harden]

Yes, and I don't think xinetd could split the read and write sides of the socket into different file descriptors even if it wanted to.

[Giulio Iotti]

On Friday, September 18, 2015 at 4:06:04 AM UTC+2, Matt Harden wrote:

Yes, and I don't think xinetd could split the read and write sides of the socket into different file descriptors even if it wanted to.

On Thu, Sep 17, 2015, 15:02 Ian Lance Taylor <ia...@golang.org> wrote:

It can't.  But we're talking about invoking the program via xinetd
here, and xinetd will pass the same connection as file descriptors 0,
1, and 2.

Thanks both, very clear now!

-- 

Giulio Iotti 

[Ted Toth]

The basic strategy worked but then I encountered the issue of shutting down the http server since this is a REST Api and it only processes one request per xinetd invocation. As a hack after I write the response I flush the writer close the connection and exit ... maybe there's a better way to do this?

[Giulio Iotti]

On Friday, September 18, 2015 at 5:29:07 PM UTC+3, Ted Toth wrote:

The basic strategy worked but then I encountered the issue of shutting down the http server since this is a REST Api and it only processes one request per xinetd invocation. As a hack after I write the response I flush the writer close the connection and exit ... maybe there's a better way to do this?

Do you really need to use inetd? What forces you to?

-- 

Giulio Iotti 

[Brad Fitzpatrick]

Before you start your server, you can call SetKeepAlivesEnabled(false):

http://golang.org/pkg/net/http/#Server.SetKeepAlivesEnabled

But using inetd/xinetd is a bad idea in general. It won't be fast at all.

[Ted Toth]

I develop code for a system which runs SELinux MLS policy and labeled networking. When a process uses a service it must connect to an instance of the service running at the same security levels (confidential, unclassified etc ...). xinetd supports execing services at the level of the connection. So xinetd is not a bad idea ... it is actually a very useful tool for my particular requirements and the performance has not been an issue. I have developed similar services using python and nodejs which were both xinetd friendly.