-
-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement a Netty module #20
Comments
@mscheibler You suggested that you might toy around with this. Has there been any work done or is there any other related info you can share? |
Sorry to say that i did not take the time to do it. My first though about this was to create several classes that implement the Netty interfaces for Channel, Codec, aso. as wrappers of the JavaCAN classes. So it would be possible to retain the JavaCAN library as zero-dependency-lib. I will try to look into this next week to see whether this is possible. As you said it might be necessary to adapt JavaCAN to use the Netty epoll. But this would mean that JavaCAN becomes dependent to Netty. |
After reading up about epoll a bit recently due to the issues, I think it would not be a bad thing to rely on Netty's well tested epoll code instead of my strictly-thread-unsafe implementation. The state of EPoll is a mess and using it correctly turned out to be fairly tricky (even the JDKs impl is not properly using it in all scenarios). Going for netty would also instantly add support for kqueue on BSD (SocketCAN is available there as well) and maybe even io_uring in the future. But I think (correct me if you find out this is wrong) the way the current JavaCAN implementation is structured, it should still be possible to provide it with our own selector interface as well as a netty integration. So maybe the project should be restructured into 3 modules
|
@mscheibler in case you haven't already worked in any netty related changes: It might be a good idea to check @splatch's implementation for PLC4X out (see #22). |
Our way in Apache PLC4X is really basic. I didn't fight for full support for NIO. What we did is just copying data between JavaCAN to netty pipeline via supplied "old IO" bridge from netty. Its not pretty, probably far from optimal, but it works. |
I broke the library into 2 parts now: javacan-core and javacan-epoll for javacan 3.x, so we are now free to add a netty module only based on javacan-core. |
I spent a few hours this week looking into the Netty internals and it seems that i imagined it easier than it will be. ;) If we succeed with the Netty integration, then it is most likely that the raw-channel implementation would be byte-stream based (as it is a |
Yep, just had a look at it myself. Many places around there are really not made for non-IP based networking. Other implementations of CAN in Netty all just implement OIO. From what I can see, we either have to implement a lot of stuff ourselves or submit patches upstream to make certain areas more compatible with non-IP based networking. CAN is pretty different to IP in many places. |
I started a branch for the netty impl: https://github.com/pschichtel/JavaCAN/tree/feature/netty |
Created an upstream issue: netty/netty#10524 |
From what I see the |
Sure, I'd want to implement OIO either way as a fallback, so if you want just create a pull request against the feature/netty branch. |
I originally planned to include a basic netty module in the 3.0.0 release, but I will keep it out for now. The I will not personally work on the netty integration as I currently don't have a use for it, but I'm happy to review any PRs that come in. |
Since the whole idea of "fluently integrating with Java NIO" kind of failed with the SPI being too closed down and troublesome in conjunction with epoll. Instead it might be a good strategy to implement this libary in the form of a Netty module. This would also probably allow to reuse netty's existing and battle tested epoll integration.
The text was updated successfully, but these errors were encountered: