a way to find the ports listened to by a `pid` (or even a `std::process::Child`)

[droundy]

Your crate works fine for finding the ports listened to by a particular process, but it would be nice if one didn't have to iterate through all processes in the case where you already know which process you're curious about!

P.S. Thanks for this cool crate!

[GyulyVGC]

Hey thanks for the suggestion!

Next versions of this crate will definitely include a more complete set of APIs.

What are you referring to specifically? Getting a listener given a PID, or a process name? (nevermind I read the title afterwards)

Anyway, I think it'd be useful to add APIs to cover the following needs:

• get Listener(s) given PID
• get Listener(s) given process name
• get Listener(s) given port

[droundy]

We need to get the ports given the PID.

David Roundy

On Tue, Mar 26, 2024, 1:35 PM Giuliano Bellini @.***> wrote:

Hey thanks for the suggestion!

Next versions of this crate will definitely include a more complete set of APIs.

What are you referring to specifically? Getting a listener given a PID, or a process name?

Anyway, I think it'd be useful to add APIs to cover the following needs:

• get Listener(s) given PID
• get Listener(s) given process name
• get Listener(s) given port

— Reply to this email directly, view it on GitHub https://github.com/GyulyVGC/listeners/issues/2#issuecomment-2021419672, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABBSKNSZDI67J2YWQMWYELY2HEYTAVCNFSM6AAAAABFJT5JLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRRGQYTSNRXGI . You are receiving this because you authored the thread.Message ID: @.***>

[GyulyVGC]

At this point I'm wondering if it makes more sense to return an HashSet<Listener> for each of the additional APIs or for instance just an HashSet<u16> for the ports.

The first option would return redundant information if used as return value of methods like get_by_pid or get_by_port, but at the same time I think it'd be the most flexible solution.

[GyulyVGC]

Here it is a further possible strategy: I could define a new struct Process including both the PID and the process name so that it'll become easier to distinguish information related to the networking part of the listener from that related to the process itself.

This is what it could look like:

pub struct Listener {
    pub process: Process,
    pub socket: SocketAddr,
}

pub struct Process {
    pub pid: u32,
    pub name: String,
}

In this way it'd be easier to define new APIs like:

pub fn get_processes_by_port(port: u16) -> Result<HashSet<Process>, Box<dyn Error>>

pub fn get_ports_by_pid(pid: u32) -> Result<HashSet<u16>, Box<dyn Error>>

pub fn get_ports_by_process_name(name: &str) -> Result<HashSet<u16>, Box<dyn Error>>

[droundy]

That sounds pretty good to me.

David Roundy

On Wed, Mar 27, 2024, 3:07 AM Giuliano Bellini @.***> wrote:

Here it is a further possible strategy: I could define a new struct Process including both the PID and the process name so that it'll become easier to distinguish information related to the networking part of the listener from that related to the process itself.

This is what it could look like:

pub struct Listener { pub process: Process, pub socket: SocketAddr,} pub struct Process { pub pid: u32, pub name: String,}

In this way it'd be easier to define new APIs like:

pub fn get_processes_by_port(port: u16) -> Result<HashSet, Box> pub fn get_ports_by_pid(pid: u32) -> Result<HashSet, Box>

— Reply to this email directly, view it on GitHub https://github.com/GyulyVGC/listeners/issues/2#issuecomment-2022375812, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABBSKOBBB7SCKANTUOQYD3Y2KD55AVCNFSM6AAAAABFJT5JLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRSGM3TKOBRGI . You are receiving this because you authored the thread.Message ID: @.***>

[GyulyVGC]

Published the requested patch in v0.2.0.

You can also check some examples of usage.