Comments (6)
I'm bikeshedding here but Is there any advantage over cmocka? The latter does not require any C++ and is already used for unit testing the dtls sliding window.
https://cmocka.org/
from af_ktls.
Awesome, Lance! Thank you.
While I was implementing and doing benchmarks of AF_KTLS, I used [1]. It is not the best possible solution, but it was/is useful (note some errors are not handled now - e.g. when a client does not connect to a TCP server, ...). I would like to reorganize this git repo and make the repo easier for development/testing/benchmarks, as suggested by @nmav in https://github.com/fridex/af_ktls/issues/17 Could we introduce one tool for automated tests and benchmarks not to diverge?
I don't have time to make a bigger review now, but few notes:
- I see that you use OpenSSL, that's great, since I use GnuTLS in [1]. We can cross-test the implementation to be sure that AF_KTLS works with OpenSSL and GnuTLS as well.
- I see that you copied parts of AF_KLTS. I would like to avoid it.
- Since we are trying to make TLS/DTLS faster in AF_KTLS in some scenarios, I would like to have benchmarks evaluated automatically during the implementation to see if we are actually making our solution faster.
- Each time there will be a bug/enhancement, we can introduce a test case in one tool to cover examples/exceptions/...
Take a look at [1] to save some time and efforts. Some parts could be reused.
[1] https://github.com/fridex/af_ktls-tool
from af_ktls.
Apart from the comment above on the framework that can certainly be the foundation of unit testing af_ktls (see Frido's comments as well), but good work. Something that caught my eye:
On gen_random() Is it intentional to test only with alphanumeric data? If not you could use RAND_bytes() and avoid that function.
About //TODO: Not checking file content?
... A wild idea could be instead of checking the file content to transmit the hash of the sent data (or send oob), so that the verifier can check the contents even of simple sends with random data.
from af_ktls.
The server basically echos the data from the client. Each client sends one (or more) strings and makes sure that the same string(s) was sent back. That way we can make sure the data is sent/transmitted correctly. It also helps that the reply is human-readable.
I think it is perfectly fine for benchmarking and correctness tests to be separate; that way we can tackle the two independently. I have taken a look at your tool, and I think we can work on combining the two.
I found C++ to be preferable in testing purposes because of the abundance of libraries and tools available, which was my main motivation to using Google Test.
Ignore the TODO. I fixed that by having the server reply.
from af_ktls.
I found C++ to be preferable in testing purposes because of the abundance of libraries and tools available, which was my main motivation to using Google Test.
Could you be more specific on that?
from af_ktls.
Could you be more specific on that?
For example, the boost libraries?
Also the fact that C code can be smoothly embedded in C++, so we are not limiting ourselves in any way from choosing C++, apart from the dependency on a C++ compiler
from af_ktls.
Related Issues (20)
- new ciphersuite: chacha20-poly1305 HOT 1
- license is GPLv3
- Copy data from multiple TLS records to userspace buffer HOT 9
- Buffer changes HOT 6
- kernel fault when decrypting to user buffer HOT 7
- Crypto API scatterwalk copy HOT 2
- MTU handling HOT 8
- Allocating too many pages HOT 1
- Sleeping with lock held HOT 1
- possible lock inversion surrounding splice HOT 2
- Remove rx async work HOT 6
- Race condition in KTLS_RECV_READY HOT 2
- peek tcp data using tcp_read_sock HOT 2
- check sock_queue_rcv_skb return value HOT 4
- DTLS sliding window should always advance
- Investigate using a single FD
- DTLS window check needs to happen after decrypt
- Support async crypto API
- Paper might also wish to cite Plan 9's devtls as related work HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from af_ktls.