Yutaka Sato wrote:
> In message <_A4133@delegate-en.ML_> on 09/14/08(21:36:06) I wrote:
> |In message <_A4131@delegate-en.ML_> on 09/13/08(18:41:30)
> |you "Andre E." <email@example.com> wrote:
> | |> You can omit PORT commands to reserve ports to be used. But reserving
> | |> a port is desirable to keep the LISTEN queue alive persistently not to
> | |> drop the connection requests for it when there is no SOCKS-client to
> | |> bind/accept from the port.
> | |Hi.
> | |
> | |I played around with the VSAP protocol as well as with the HTTP ACCEPT
> | |method
> | |and it works a long as I'm only dealing with one client. This is
> | |probably due to the fact
> | |that once a client connects to the opened port, this port becomes bound
> | |by this client
> | |so no other client can connect to this port.
> |To enable multiple-parallel clients to do bind on the same port,
> |you need to do either A) reserving the port with the PORT parameter
> |to be shared in child DeleGate processes, or B) running DeleGate in
> |a single process mode with option "-d+7" or so to share dynamically
> |bound ports among client threads in the process.
> Sorry, I noticed B) is not true in the exsisting implementation.
> It can be enabled with the enclosed patch.
Thanks again for all the effort. Your patch works and your explanation
actually helped a lot.
In another message from you, you said the die VSAP protocol could wrap
SOCKS if necessary.
Does this mean that my SOCKS client could talk with a VSAP server and
for example use the CONNECT methods?
If so, do I need to modify the client in some way or do I just turn it
on with a server option?