How about decouple Socket implementation in Proxy?

[CookPh]

TechnitiumLibrary is a good library!

I have a query regarding the current Proxy implementation. Specifically, in methods like IProxyServerConnectionManager.ConnectAsync, the use of System.Net.Sockets ties the remote connection to the same process.

What if we leverage IVirtualSocket to replace the standard socket? The IVirtualSocket interface might looks like

    public interface IVirtualSocket : IDisposable
    {
        Stream Stream { get; }
        EndPoint LocalEndPoint { get; }
        EndPoint RemoveEndPoint { get; }
        Task CloseAsync();
    }

This approach will untangle the dependency on Socket, leading to increased flexibility

I'm interested in your thoughts on this change. If you're aligned with this idea, I can submit the patch within a few days.

[ShreyasZare]

Thanks for the post and compliments. The proxy implementation returns Socket object so that the application that is using the proxy client library will get the socket object to proceed with whatever protocol it wishes to implement.

I am not getting the use-case of replacing Socket with an interface. Can you elaborate it?

[CookPh]

In certain networks, there might be additional restrictions imposed on outgoing IPs. Let's consider a scenario where we are developing a proxy for a university. The university has already purchased access to ACM(https://libraries.acm.org/subscriptions-access). Every faculty member and student can access ACM resources using IP 8.8.8.8.

For all other types of traffic, it can be sent directly through the proxy. Due to the substantial load of traffic, 3 proxy servers are employed. Whenever a student seeks to access the web, the WPAD (Web Proxy Auto-Discovery Protocol) returns one of the three proxy servers. The 4th proxy with IP 8.8.8.8 is exclusively designated for accessing ACM.

Here's the issue: The first 3 proxies are unable to directly send requests to ACM. All requests to ACM must be routed through the 4th proxy. While a proxy chain (proxy over proxy) might function for TCP/IP, it doesn't work for RDMA (Remote Direct Memory Access) connections. Additionally, using a proxy chain might result in lower efficiency when compared to the use of Stream.

I just went through the code, and IMHO, making the change from "Socket viaSocket" to "IVirtualSocket viaSocket" is sufficient.

[ShreyasZare]

Thanks for the details. I have no experience working with RDMA. I would suggest that you can have an implementation of IProxyServerConnectionManager such that the class connects with RDMA and return Socket object so that the rest of the proxy code works as usual. Updating the code at this point is not feasible since it is being used in multiple other projects and would require substantial changes everywhere.

[CookPh]

Got that.

Can TechnitiumLibrary.Net handle proxy chains that involve mixed protocols? For example: (client)<-------->(http proxy server)<--------------->(socks proxy server)<---------------->(remote server)

[ShreyasZare]

Got that.

Can TechnitiumLibrary.Net handle proxy chains that involve mixed protocols? For example: (client)<-------->(http proxy server)<--------------->(socks proxy server)<---------------->(remote server)

The proxy server/client code in the library was designed to allow them to be chained in code. So, you can have a SOCKS5 proxy server running which uses a HTTP proxy client as its connection manager effectively converting SOCKS5 to HTTP proxy.

Also, the proxy client has ViaProxy property which can be used to chain multiple proxy servers that already exists. The client will ensure to connect to the ViaProxy server first and then initiate the actual proxy connection through it.