Can support PID? about proxifyre

[wiresock]

While it is possible, utilizing Process IDs (PIDs) might introduce complications due to their dynamic nature. Consequently, the average user could face challenges in determining these PIDs, thus potentially limiting the approach's effectiveness.

[23233]

@wiresock
Although this will certainly increase complexity, I'm not sure how many people share this profound need with me. However, in the realm of multi-instances, it is a necessary behavior because all application names are the same in multi-instances. To differentiate them, I can only rely on the PID. I'm wondering if there is any other way, my friend, to set up proxies for each individual Chrome instance within a bunch of identically named instances? Thank you.

[wiresock]

@23233 I understand your requirement to modify the socksify class library to function based on process IDs rather than application names. Indeed, it's entirely feasible for you to fork the repository and tailor the code to suit your needs. However, I have certain reservations about modifying this project in situ for the following reasons:

1. There appears to be a minimal user base who require the assignment of different proxies to distinct application instances.
2. Target applications may share states among instances. If instances possess differing connection parameters, these applications could potentially malfunction.
3. Currently, the demo application loads configuration from a file, a process that is relatively straightforward due to the persistent nature of application names, unlike the transient nature of process IDs. In this context, do you have any concept of how the demo app should appear?

[23233]

@wiresock

Perhaps I was heading in the wrong direction with my previous questions. Please accept my apologies, as I spent several hours examining the repository source code without making any progress, which led me to seek your assistance. Currently, we have implemented the following behaviors based on PID:

1. Pre-loading a large number of SOCKS5 proxies and maintaining their availability.
2. Setting an allocation rule, such as assigning one proxy to one instance or one proxy for every five instances.
3. Parsing the number of instances (PIDs) based on a specified process name, such as "chrome," and then applying the allocation rule to distribute the proxies.

With this approach, we don't need to worry about the PID changing when an instance is opened, closed, and reopened. Instead, we allocate proxies to multiple instances based on the allocation rule, rather than specifying a specific existing PID.

Our daily routine involves maintaining the availability of the proxy pool and managing the allocation rule.

Thank you.

[wiresock]

@23233

Thank you for your detailed explanation regarding your current implementation. I appreciate your diligence in examining the repository source code, and it is absolutely fine that you reached out for assistance. That's what I'm here for!

I understand your approach to pre-loading SOCKS5 proxies, establishing allocation rules, and then parsing the number of instances based on a specified process name for proxy distribution. This indeed seems like a comprehensive strategy to deal with instances being opened, closed, and reopened, and does negate the need to focus on a specific PID.

However, there is a potential issue that you might face with this method: If your application shares state between instances, you could encounter complications or misbehave.

It seems like you have already implemented the behaviors you described. Therefore, I'm curious as to what assistance you're seeking. Are there any specific problems or challenges you've encountered in your current implementation? Are there aspects you want to improve? Your answers will help me better understand your needs and provide more targeted assistance.