forum.vdsworld.com

[webdaddy]

OK this is probably directed at PGWare but interesting to say the least. Im developing a really intense product right now and have been using vdsipp for awhile now in most of my internet based applications. So tonight I decided that I was gonna port some of the applications from vdsipp to vdstcp suite which I just purchased this past week. I left 1 application still use vdsipp and all the other have since been changed due to the nature of what im trying to do. Interesting enough though is that when I open up a bunch of sockets in vdstcp those applications behave but the last application to use vdsipp CPU spikes and it only has 1 socket that it is listening on. I an nmapping the client that this is running on. What appears to be happening but I cant confirm is that nmap opens up all 99 sockets on the last remaining vdsipp application causing the CPU to go through the roof. Now since the product is a security product I cant let this slide so I am gonna change the last remaining application to vdstcp but was wondering if this is normal. If so basically nmapping a host that has ANY vdsipp listening sockets will cause the system to max out on CPU. I confirmed this. If you nmap a host that has vdsipp it basically will max out the CPU and never recover. PGWare can you confirm this maybe? Is there a fix for this. I have 1 application in the suite that I really dont want to have to change BUT if this is happening I dont see much of a choice because it only takes a few minutes before the machines freeze up if they are scanning with NMap...

I know its not supported but I do love the capabilities in vdsipp and if there is a fix I would like to figure out how to prevent this from happening.

Thanks.

[PGWARE]

Well I'm not sure what an nmap is. But I think you are using TCP or the UDP protocols? If so each one of those uses a timer which constanty checks for incoming messages. Having all 99 sockets open and checking would cause 99 timers also to run which yes would cause a lot of cpu to go.

The thing was in earlier versions of VDSIPP the threshold of the timer to trigger was around 2-3 seconds. The problem with this was messages could be missed, so I had to set the timers around to under half a second. 99 of these are going to really hit at the cpu.

The workaround to this would be to raise the timer in each of the server protocols, but the potential to miss incoming messages would be very high thus making the protocol and server unreliable.

[webdaddy]

Here is a link for information on NMap. You can download a copy and see what I mean if you want.

http://www.insecure.org/nmap/

This happens with just 1 listening socket. It doesnt matter. For instance if I do something like.

INTERNET CREATE,1
INTERNET ACTIVATE,1,2500

so im listening on port 2500 and simply ignore any messages that are received and then scan the system where my application is running it maxes out the CPU with 1 listening socket.

I'm not 100% sure what NMap does to cause it to max out but it does.