Support for wildcard proxies?

[endigma]

Support for something like *.domain.example would be useful in the domainName field. This would allow for sending all requests on a particular subdomain to a separate router. An example of where this might be practical is a multi-box server setup with a raspberry pi/etc acting as a router for different servers.

[endigma]

Currently an infrared -> infrared -> minecraft server system works with explicit declarations but it'd be nice to be able to point wildcard records at a particular router.

[DoubleCheck0001]

If I’m not mistaken, it should work, you just don’t need the *. at the beginning. If you use domain.example.com in the domainName field, it should catch all sub-domains on that.

[endigma]

with

{
    "domainName": "mc.domain.com",
    "proxyTo": "192.168.1.20:25565",
    "disconnectMessage": "Sorry {{username}}, the server is still offline.",
    "offlineStatus": {
        "versionName": "Offline",
        "protocolNumber": 754,
        "maxPlayers": 0,
        "playersOnline": 0,
        "motd": "Server is currently offline."
    }
}

on the first node, 'router'

(substituted domains, these are not the issue)

the proxy returns

[x] 192.168.1.1:47774 closed connection with :25565; error: no proxy with uid test.mc.domain.com@:25565

on the first node in the chain, i.e. the 'router', the 2nd node, i.e. the specific box's 'router' does not receive this request at all.

which appears as though this wildcard does not work as you say

to be clear, my setup is like this: pi -> 'router', running nothing but infrared in this setup, exposed on 25565 to wider internet pi routes requests by infrared to box1 and box2, which each have their own infrared to proxy to their mc servers

the request on a non-existent record, the wildcard request, never makes it past the 1st node.

[endigma]

// Load returns the value stored in the map for a key, or nil if no
// value is present.
// The ok result indicates whether value was found in the map.
func (m *Map) Load(key interface{}) (value interface{}, ok bool) {
	read, _ := m.read.Load().(readOnly)
	e, ok := read.m[key]
	if !ok && read.amended {
		m.mu.Lock()
		// Avoid reporting a spurious miss if m.dirty got promoted while we were
		// blocked on m.mu. (If further loads of the same key will not miss, it's
		// not worth copying the dirty map for this key.)
		read, _ = m.read.Load().(readOnly)
		e, ok = read.m[key]
		if !ok && read.amended {
			e, ok = m.dirty[key]
			// Regardless of whether the entry was present, record a miss: this key
			// will take the slow path until the dirty map is promoted to the read
			// map.
			m.missLocked()
		}
		m.mu.Unlock()
	}
	if !ok {
		return nil, false
	}
	return e.load()
}

I had a peek at map.go which is where I'm pretty sure this key reading is taking place, and I don't see any indication that this functionality should happen, as maps in Go iirc only provide exact results, and there's no provision here for filtering wildcards/subdomains. I could be wrong however, as with the web of interface{}s it's hard to know exactly what data types are being used for a person who hasn't looked at the codebase extensively.

[haveachin]

@endigma is right. I use the thread safe version of a map, but it only checks for an exact match. See: https://github.com/haveachin/infrared/blob/ad46f32ce6f014d26f8a139ef7b4a5b24aab261f/gateway.go#L159 I see your use case and will add a wildcard for the domain/subdomains as soon as I have time.

[endigma]

A ** doublestar compatible matcher might be useful for proper glob patterns, so you could do things like mc.*.domain, with full integrated wildcards, or even mc.* and just take everything with the left-most section being mc. this would be an edge case but a competent glob matcher would be really cool.

If you think this functionality matches scope, this could be expanded into a domain matching PR, with a capable glob matcher solving both the multi-domain pattern and the wildcard pattern.

[base2code]

How is the current status on implementing it? Will the feature be in the rewrite?

[haveachin]

Nothing regarding wildcards is implemented yet, but there are plans to add support for wildcards in the refactor. And always feel free to poke around in the master or refactor branch yourself. It's always good to have more hands and eyes on the code base :)