Newbie: Keep TCP socket open

[Alan Wright]

Hi Folks,
I am newbie to Python, but have successfully created a simple client and
server setup, I have one issue though.

I am trying to test a box by sending many TCP conns (WHILE loop) but not
closing them with a FIN/RST. However, no matter what i do, i cannot get the
loop to stop sending FIN from the client.

Any clues?

Here is my current script

#!/usr/bin/python

import socket,sys
from numpy import *
num1=0

while (num1<=10) :

s = socket.socket(s ocket.AF_INET, socket.SOCK_STR EAM)
s.settimeout(10 .0)
s.connect(("10. 1.1.69", 50008)) # SMTP
print s.recv(1024) + '\n',
num1=num1+1
#s.close()
sys.exit(1)

[s0suk3]

On May 19, 10:25 am, "Alan Wright" <alan.wri...@vo lubill.comwrote :

Hi Folks,
I am newbie to Python, but have successfully created a simple client and
server setup, I have one issue though.

I am trying to test a box by sending many TCP conns (WHILE loop) but not
closing them with a FIN/RST. However, no matter what i do, i cannot get the
loop to stop sending FIN from the client.

Any clues?

Here is my current script

#!/usr/bin/python

import socket,sys
from numpy import *
num1=0

while (num1<=10) :

s = socket.socket(s ocket.AF_INET, socket.SOCK_STR EAM)
s.settimeout(10 .0)
s.connect(("10. 1.1.69", 50008)) # SMTP
print s.recv(1024) + '\n',
num1=num1+1
#s.close()

sys.exit(1)

socket.socket instances do an implicit close() on the socket when the
object is destructed (in this case, it's destructed when it is garbage-
collected). What's happening is that on each iteration, the variable
"s", which references the socket.socket instance, is assigned to a new
socket.socket instance, therefore the instance of the previous
iteration is no longer referenced by "s", and since it's no longer
referenced by anything, the instance is garbage-collected,
automatically imposing an implicit close() on that instance. A simple
solution could be to create a list and append the socket.socket
instance of each iteration to that list, that way the instances would
remain referenced in the list and not be garbage-collected; though you
might be able to find a more elegant solution.

Sebastian

[Irmen de Jong]

Alan Wright wrote:

while (num1<=10) :

s = socket.socket(s ocket.AF_INET, socket.SOCK_STR EAM)
s.settimeout(10 .0)
s.connect(("10. 1.1.69", 50008)) # SMTP
print s.recv(1024) + '\n',
num1=num1+1
#s.close()
sys.exit(1)

I think the following is happening:
Reusing the 's' object for every new socket will make Python to garbage
collect the previous ones. Garbage collecting a socket will likely close() it.
Also after creating all sockets your program exits. I guess either Python or the
operating system itself will go close all the sockets.
Try putting every new socket you make into a big list instead, so that Python can't
garbage collect it. And put your program to sleep at the end.

import time
allsockets=[]

while (...):
s=socket.socket (...
allsockets.appe nd(s)
s.settimeout(.. .
...

time.sleep(9999 9)

--irmen

[Alan Wright]

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

TIA

Alan
<s0****@gmail.c omwrote in message
news:e8******** *************** ***********@c58 g2000hsc.google groups.com...

On May 19, 10:25 am, "Alan Wright" <alan.wri...@vo lubill.comwrote :

>Hi Folks,
I am newbie to Python, but have successfully created a simple client and
server setup, I have one issue though.

I am trying to test a box by sending many TCP conns (WHILE loop) but not
closing them with a FIN/RST. However, no matter what i do, i cannot get
the
loop to stop sending FIN from the client.

Any clues?

Here is my current script

#!/usr/bin/python

import socket,sys
from numpy import *
num1=0

while (num1<=10) :

s = socket.socket(s ocket.AF_INET, socket.SOCK_STR EAM)
s.settimeout(10 .0)
s.connect(("10. 1.1.69", 50008)) # SMTP
print s.recv(1024) + '\n',
num1=num1+1
#s.close()

sys.exit(1)

socket.socket instances do an implicit close() on the socket when the
object is destructed (in this case, it's destructed when it is garbage-
collected). What's happening is that on each iteration, the variable
"s", which references the socket.socket instance, is assigned to a new
socket.socket instance, therefore the instance of the previous
iteration is no longer referenced by "s", and since it's no longer
referenced by anything, the instance is garbage-collected,
automatically imposing an implicit close() on that instance. A simple
solution could be to create a list and append the socket.socket
instance of each iteration to that list, that way the instances would
remain referenced in the list and not be garbage-collected; though you
might be able to find a more elegant solution.

Sebastian

[Ghirai]

On Mon, 19 May 2008 20:25:57 +0100
"Alan Wright" <al*********@vo lubill.comwrote :

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

TIA

Try to use scapy to send raw empty packets with S flag set.
Also use Linux/BSD if you're trying this on Windows.

--
Regards,
Ghirai.

[Alan Wright]

Ghirai,
Scapy does the same, only it sends RST and not FIN, so still no help

send(IP(dst="10 .1.1.2")/TCP(dport=50000 ,flags="S"))

Only have windows at the moment sadly.

Alan

"Ghirai" <gh****@ghirai. comwrote in message
news:ma******** *************** *************** *@python.org...

On Mon, 19 May 2008 20:25:57 +0100
"Alan Wright" <al*********@vo lubill.comwrote :

>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

TIA

Try to use scapy to send raw empty packets with S flag set.
Also use Linux/BSD if you're trying this on Windows.

--
Regards,
Ghirai.

[Ghirai]

On Mon, 19 May 2008 23:50:50 +0100
"Alan Wright" <al*********@vo lubill.comwrote :

Ghirai,
Scapy does the same, only it sends RST and not FIN, so still no help

send(IP(dst="10 .1.1.2")/TCP(dport=50000 ,flags="S"))

Only have windows at the moment sadly.

Alan

Are you sure there's no firewall or something else between you and the
remote host?

Because i just tried that command with scapy and it didn't send any other packets
except what it was told (1 packet with SYN flag set).

I haven't tried on windows though.

--
Regards,
Ghirai.

[Roy Smith]

In article <DK************ *************** ***@pipex.net>,
"Alan Wright" <al*********@vo lubill.comwrote :

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.

[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" <ro*@panix.comw rote in message
news:ro******** *************** @70-1-84-166.area1.spcsd ns.net...

In article <DK************ *************** ***@pipex.net>,
"Alan Wright" <al*********@vo lubill.comwrote :

>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.

[Alan Wright]

Same on FC8, sends RST after it sees SYN/ACK

"Ghirai" <gh****@ghirai. comwrote in message
news:ma******** *************** *************** *@python.org...

On Mon, 19 May 2008 23:50:50 +0100
"Alan Wright" <al*********@vo lubill.comwrote :

>Ghirai,
Scapy does the same, only it sends RST and not FIN, so still no help

send(IP(dst="10 .1.1.2")/TCP(dport=50000 ,flags="S"))

Only have windows at the moment sadly.

Alan

Are you sure there's no firewall or something else between you and the
remote host?

Because i just tried that command with scapy and it didn't send any other
packets
except what it was told (1 packet with SYN flag set).

I haven't tried on windows though.

--
Regards,
Ghirai.