FlorianHockmann opened a new pull request #1559: URL: https://github.com/apache/tinkerpop/pull/1559
https://issues.apache.org/jira/browse/TINKERPOP-2695 WebSocket support was only added in .NET 6 which made it necessary to explicitly add .NET 6 as an additional target framework. Compression will now be enabled by default on .NET 6 as it's only available there. This made it necessary to add conditional compilation based on the target framework. ### Package validation I also enabled [package validation](https://docs.microsoft.com/en-us/dotnet/fundamentals/package-validation/overview) so we a) notice if we introduce breaking changes by accident and b) ensure that our code compiled against .NET Standard 2.0 can also be run against .NET 6. This already helped me to keep the breaking change here to a minimum. It's just an added optional parameter here to be able to disable compression. We could refactor the `GremlinClient` constructors in the future in a way to avoid this problem of having to add optional parameters for new config options which is always a breaking change. The validation is executed on `dotnet pack` which gets already executed via `mvn verify` and is therefore also part of our GH actions. Compatibility errors that we know about and that we accept should be added to the `CompatibilitySuppressions.xml` file which can also be generated via ``` dotnet pack Gremlin.Net.csproj /p:GenerateCompatibilitySuppressionFile=true ``` ### Possibly vulnerable to attacks (CRIME / BREACH) WebSocket compression can be problematic due to attacks like CRIME/BREACH as noted in TINKERPOP-2682. So, I added an option to easily disable it for applications that might be vulnerable and added docs to make users aware of this. I guess we should discuss how we want to deal with this in general as it's not specific to .NET. So, should we simply add similar notes to the Java/Python docs? ### Benchmarks Lastly, some quick benchmarks I ran on my machine: **GraphBinary:** Without compression: Packets transmitted: 3594 Bytes transmitted: 7MB Runtime: 1min 1.5sec With compression: Packets transmitted: 62 (1.7%) Bytes transmitted: 34KB (0.5%) Runtime: 1.3sec **GraphSON 3:** Without compression: Packets transmitted: 12029 Bytes transmitted: 25MB Runtime: 1min 40sec With compression: Packets transmitted: 116 (1.0%) Bytes transmitted: 103KB (0.4%) Runtime: 1min 39sec So, both for GraphSON as well as for GraphBinary the network traffic shrinks by a factor of ~100 while the total runtime is not affected. Note that this was just a very simple benchmark (I used the same traversal as @spmallette used in the PRs for Python and Java, just with a smaller number of iterations to keep the runtime to a minimum). The results will of course vary for different traversals / graphs. VOTE +1 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
