added wrapper type and todos

[AnkurRathore]

@GlenDC I have attempted to add some wrapper types, and I have some doubts implementing them which I have put as TODO in the comments. I would need your guidance on this.

[GlenDC]

Let me know if my comments in this review are sufficient guidance or in case you need more detailed guidance. If the latter try to be more specific on where exactly you want my guidance with.

[GlenDC]

You can easier define this by using Default in the #[derive(..)] above and set #[default] above Dual,.

[GlenDC]

Originally I wanted to go for a single IP Mode indeed, and work with wrapper types. However I think it makes more sense to define 2 enums:

enum DnsResolveIpMode
    dual (default)
    singleIpV4
    singleIpV6
    dualPreferIpv4

enum ConnectIpMode
    dual (default)
    ipv4
    ipv6

Don't think these belong in rama-tcp though. Probably more like in rama-net or so.

[AnkurRathore]

Do I need to put these in rama-net?

[GlenDC]

Yes as these are not specific to tcp. E.g. in a future version we'll also support udp. And other packages such as Dns might also make use of it for w/e. The common denominator is that it's all related to network protocols, as such rama-net.

You can put it in a file created as rama-net/src/mode.rs and just pub mod mode in the lib.rs file of that crate.

[GlenDC]

I think it's in async fn tcp_connect_inner<State, Dns, Connector>( that you'll want to check for DnsResolveIpMode.

And it's in the location where we actually establish a tcp stream that you'll check for ConnectIpMode.

Originally I was thinking to also automatically let one influence the other, but I think it makes more sense to just let the user worry about that. E.g. if user selects Ipv6-only for DNS and ipv4-only for Connect, then that obviously will fail, but that is up to the user to then fix. No point in trying to do anything about that, as the only reasonable thing to do would be to return some kind of error, so let's not bother with that as the current error will already be fine enough.

[GlenDC]

Hi @AnkurRathore , not that it's a blocker or urgent. But given this is already a month stale. I do want to at least check in.

• Are you stuck?
• Need guidance, mentoring, or help of any kind?
• Or did you move one and want to hand this over to someone else?

EIther and everything is fine. And hope you're in good health and condition. Take care!

[AnkurRathore]

Hi @GlenDC ,
Apologies for the delay and thank you for checking in. I truly appreciate your patience.
There are two main reasons for the delay:

1. I’ve been dealing with some personal matters, which took up most of my time. I’m now getting back on track and regaining focus.
2. When I started reviewing the Rust codebase, I felt a bit overwhelmed and struggled with some of the language intricacies. To address this, I’ve been dedicating time to deepening my understanding of Rust.

I would still love to work on this, but I want to ensure I’m not impacting the release schedule. If you need this prioritized or handed over, I completely understand.
Thank you again for your understanding and support. I hope this clarifies my situation. Please let me know how you’d like me to proceed.