Newbie: Keep TCP socket open

[Alan Wright]

Thanks Roy

Any ideas how to code this child process stuff, as I said I am newbie and 
not from a coding background

to be honest ideally yes, i'd get 50K, but if i can get above 30K that would 
be OK

Alan

"Roy Smith" <roy at panix.com> wrote in message 
news:roy-27A881.20583919052008 at 70-1-84-166.area1.spcsdns.net...
> In article <DK6dnSffU4LRSazVnZ2dnUVZ8qqlnZ2d at pipex.net>,
> "Alan Wright" <alan.wright at volubill.com> wrote:
>
>> Thanks for the feedback.
>>
>> Using the socket in a list is great
>>
>> However, as i imagined, I now get a limit of around 1500 conns before the
>> system crashes out, also i have noticed, that the ports loop back to 1025
>> when they hit 5000.
>>
>> Any ideas on how to make the list/socket get to around 50K
>
> Yikes.  Not on any box I know of.  A given process is limited in how many
> descriptors it can have open at once.  I don't know of any that will allow
> anywhere near 50k.  Somewhere in the 1-2000 range would be more typical.
> The 1500 you report is not at all surprising.
>
> You might try creating a bunch of child processes with os.system() or
> something of that ilk.  Create 50 processes and have each one open 1000
> sockets.
>
> The next thing you have to worry about is whether the OS can handle 50k
> file descriptors open per-system.  Or 50k sockets, or TCP connections.  I
> wouldn't be too surprised if many systems couldn't.  The address space 
> (TCP
> port numbers) is 16-bit (unsigned), or about 65k, but you may well run 
> into
> some other system limit long before you exhaust the theoretically 
> available
> ports.
>
> Something like Scapy, recommended by others, may indeed be able to 
> generate
> all those SYN packets you want, but that doesn't mean you'll get all the
> open connections you seek.  You send a SYN packet to the remote host, and
> it sends back a SYN/ACK.  The local kernel now sees a SYN/ACK packet for a
> port it doesn't know about.  I'm not sure what the RFCs say about that, 
> but
> I wouldn't be surprised if the kernel ends up sending a RST or maybe a FIN
> or something like that.  The kernel owns the ports; it's not nice to try
> and mess with them on your own.