Hi, Daryn Sharp, Aaron T. Myers, I have updated the patch, please help to review if you time allow.
Add some unit tests and results of measuring the performance improvement
I have finished the initial Benchmark with RPC Call Benchmark and also added two UTs in the latest patch, the benchmark result shows the patch improve ~4X on the throughput of RPC call, now the performance of PRIVACY is close to INTEGRITY’s, here is the detail data of total calls per second:
||r:4 c:1 s:1 m:1024
|| r:4 c:30 s:30 m:1024
|PRIVACY (AES with HadoopOpensslCodec)
|PRIVACY (AES with HadoopJceCodec)
|PRIVACY (Original DES)
Why not use javax cipher libraries? Any number of ciphers could be used now and in the future w/o code change. The aes ciphers are supposed to use aes-ni intrinsics when available.
JDK cipher doesn’t take advantage of Intel AES-NI very well until JDK 9 (JDK-8143925 Improve JDK 9 AES-CTR with 4~6x gain), so I think using Crypto Stream in Hadoop should be a good choice.
Should use a custom sasl client/server that delegates to the actual sasl instance. The ipc layer changes would be minimal and easier to maintain.
It is hard to separate current logic to independent sasl client/server with minimal changes, I have move the logic to separate method for minimizing the changes.
The cipher options appears to be present in every packet. If so, it should only be in the negotiate/initiate messages.
The cipher option only appears in SASL negotiate/initiate.