NetSender flexible destination control

Currently all NetSender requests are destined for the same service, which is specified by the service host and port (sh and sp params respectively) which default to netreceiver.appspot.com:80

As functionality migrates over time from NetReceiver (NR) to new services, such as VidGrind (VG), clients require more flexible destination control. Specifically, clients need to be able to specify destinations per request. Further, partners may wish to use alternative services that they manage.

The immediate case in hand is video. In order to migrate video from NR to VG, /recv requests need to go to VG while other requests (/poll, /config, /vars) need to continue to go to NR. This hybrid arrangement will continue for as long as we federate services, possibly indefinitely.

It is proposed that the sh param be generalized to be a comma-separated list of key/value pairs where key are request names and values are services, e.g.,

#!

sh poll=netreceiver.appspot.com,recv=vidgrind.appspot.com

When the key is default or omitted it represents the default, e.g.,

#!

sh default=netreceiver.appspot.com,recv=vidgrind.appspot.com

#!

sh netreceiver.appspot.com,recv=vidgrind.appspot.com

The latter is backwards compatible with the current config:

sh netreceiver.appspot.com

For convenience the port can be included rather than using the sp param, e.g., to service VG requests on port 8080:

#!

sh default=netreceiver.appspot.com,recv=vidgrind.appspot.com:8080

Or for testing with 2 instances of dev_appserver, one running NR on port 8080 and the other VG on port 80881:

#!

sh default=localhost:8080,recv=localhost:8081

The implementation is quite straightforward. Netsender.Config() would scan the sh param into a map[string]string, which would be constructed so as to always contain at least the default key. Netsender.Send() would check the map for a per-request destination and use that if present, or the default value if absent.

Comments (3)