Yutaka Sato wrote:
> Hi,
>
> 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." <pzyhqbdyi-q45w4pnby3y6.ml@delegate.org> 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.
>
> Cheers,
> Yutaka
>   
Hi Yutaka.

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?

Best regards,
Andre