Allow Kitura-Net to only listen on one network address

[TaborKelly]

Description

@billabt was nice enough to add support for this at the BlueSocket layer here. However, I really want to use that functionality to fix Kitura/Kitura#1450.

I also have code ready to go for Kitura/Kitura-NIO#205 and Kitura.

Motivation and Context

This is necessary to close Kitura/Kitura#1450. Should I open another issue for Kitura-Net?

How Has This Been Tested?

Manual testing by myself. I also modified the test harness to use the new code path.

Checklist:

• I have submitted a CLA form
• If applicable, I have updated the documentation accordingly.
• If applicable, I have added tests to cover my changes.

[CLAassistant]

All committers have signed the CLA.

[djones6]

Thank you for the PRs! Some comments on the duplication of functions which I think can be avoided.

Also, I'm not sure that node would be my choice of parameter name - could we call it address instead?

[djones6]

The addition of the optional function parameter is non-breaking, so I don't think it's necessary to duplicate the functions here. In the (port:node:delegate:) case below, you'd need to default node to nil.

[TaborKelly]

I was trying not to break the public Server protocol where default initializers are not allowed.

Are you saying that I can have them both (listen(on) and listen(on:node)) defined in the Server protocol but only listen(on:node) with a default initializer in the actual implementation? If so, that would surely be preferable.

[TaborKelly]

If I remove listen(on) from HTTPServer but leave it in the Server protocol definition (where I can't have a default initializer) swift isn't happy:

$ swift build
/Users/tabor.kelly/work/taborkelly/Kitura-Net/Sources/KituraNet/HTTP/HTTPServer.swift:41:14: error: type 'HTTPServer' does not conform to protocol 'Server'
public class HTTPServer: Server {
             ^
/Users/tabor.kelly/work/taborkelly/Kitura-Net/Sources/KituraNet/Server/Server.swift:45:10: note: protocol requires function 'listen(on:)' with type '(Int) throws -> ()'; do you want to add a stub?
    func listen(on port: Int) throws

Please note, this is with the default initializer in HTTPServer.swift:

    public func listen(on port: Int, node: String? = nil) throws {
        self.port = port
        self.node = node
        try listen(.inet(port, node))
    }

[pushkarnk]

Hmm. A known work around to this is writing a protocol extension with a method that has the default valued parameter.

extension Server {
    func listen(on port: Int, node: String? = nil) {
        listen(on: port, node: node)
    }
}

[djones6]

Same comment as for FastCGIServer - shouldn't need two functions as long as node is given a default of nil

[TaborKelly]

As for naming, I am happy to change node to address. I used node to match BlueSocket which in turn matches getaddrinfo.

[djones6]

@TaborKelly I tried out @pushkarnk's suggestion with the protocol extension here, and it seems to work:
djones6@46a097c

Here's a quick hack up of the corresponding Kitura change to surface the new option:
djones6/Kitura@a5539cf

[TaborKelly]

@djones6, @pushkarnk,

Thanks of the help. djones, I used your code almost verbatim. I only fixed up some comments. I think the changed (stripped) whitespace was in your version, and I just copied it. I'm fine with it if you are, but I am also willing to re-add trailing whitespace depending on what you folks want.

[djones6]

The changes look good, however could we change the documentation comment for address to be more descriptive (I've given some suggestions). There are several instances of the same comment that would need updating, and similarly for the NIO PR.

[djones6]

Could we document this parameter as:

The address of a network interface to listen on, for example "localhost". The default is nil, which listens for connections on all interfaces.

[djones6]

How about

The address of the network interface to listen on. Defaults to nil, which means this server will listen on all interfaces.

[TaborKelly]

I think that I changed all the documentation comments to match your suggested wording. If we wanted to we could change the word interfaces to addresses as it would be more correct. Well, at least for Kitura-Net. I suspect the Kitura-NIO is only listening on IPv4 addresses, but I haven't verified it.