Actually I'm implementing a work generator module that can either run embedded inside poolserverj or as a standalone. The reason for the latter is that psj can get pretty busy with other things as well so you may still want to spread that load across two servers... The standalone will not use rpc. It will simply stream work to psj in a compact binary format and psj controls the flow by sending stop/start signals.
Neat! I couldn't figure out whether that made sense or not; work generation is embarassingly parallel and easy to make threaded, but some of the other bits of a pool server aren't. I wasn't sure how quickly the other bits would become a bottleneck.
Also: I appear to now have merged mining working without using merged-mining-proxy! Just for a single aux chain at the moment and it's rather untested, but still. Uses
https://github.com/makomk/pushpool/tree/local-work-gen-mm and a very slightly patched version of namecoin in
https://github.com/makomk/bitcoin/tree/namecoin-getauxblock-prevhash - each chain gets its own shares table, and in theory shares are recorded as stale for each chain independently of the others. (In practice this isn't quite working right; shares that are stale on the parent chain are treated as stale for them all, and the client is only told if they're stale on the parent.)
"auxchains" : [
{
"rpc.url" : "http://127.0.0.1:9337/", "rpc.user" : "", "rpc.pass" : "foo",
"stmt.sharelog":"INSERT INTO shares_nc (rem_host, username, our_result, upstream_result, reason, solution) VALUES (?, ?, ?, ?, ?, ?)"
}
]