Dear group
I am regularly asked by Comodo FireWall to allow a certain outgoing request. I looked it up with WSping and Currports by Nirsoft and my problem is that I can not see which program is behind this process.
Have a look:
http://i55.tinypic.com/10o1tas.png
Perhaps you can tell me how to disclose this mysterious process.
thank you
My guess would be Firefox or Tor - Akamai is an internet acceleration company.
From their Wikipedia entry
[i]Akamai transparently mirrors content—sometimes all site content including HTML, CSS, and software downloads, and sometimes just media objects such as audio, graphics, animation, and video—from customer servers. Though the domain name (but not subdomain) is the same, the IP address points to an Akamai server rather than the customer's server. The Akamai server is automatically picked depending on the type of content and the user's network location.The benefit is that users can receive content from whichever Akamai server is close to them or has a good connection, leading to faster download times and less vulnerability to network congestion or outages.
In addition to image caching, Akamai provides services which accelerate dynamic and personalized content, J2EE-compliant applications, and streaming media to the extent that such services frame a localized perspective.[/i]
HTH
Ewen 
Ewen
thank you for clarifying that up though I did know about that. But anyway that does not help me.
Look at this page and you know what I mean perhaps:
The point is that my tool that is highly praised tells me nothing about the outgoing call (process zero…=). I mean what I presented here is only an example. What I am asking is whether you know a more sophisticated why to disclose the process.
Any person, admin or nor, should care about stuff like this and well, would be great to know not only that something wants to connect to the outside but also what it is
Sometimes another driver is blocking view for CIS and then it can’t tell what process is making the outgoing connection. I am not sure if that can be (easily) fixed.
What your image is showing, at least with the svchost and ‘unknown’ process, is a connection that was made to AKAMAI by svchost, probably for product updates, either by Windows or some other application that also uses svchost, that has subsequently closed (TIME_WAIT)
Essentially, once the two parties involved in the TCP connection complete their FIN/ACK(s) the connection is passed from the original process (svchost in this case) to (under Windows) System Idle Process, which has a PID of 0 (zero) and enters a TIME_WAIT state. It will persist in this condition until the socket is closed and is available for reuse.
Radaghast I am pendergasted.
Thank you for this nice explanation. I assume what you described is always the case when PID zero is involved. Always the case means that a process needs or makes use of svchost and remains active or more to the point it holds the pipe open in this way.
For me as curious users this means I have to monitor in such cases svchost more closely. For example with tools by Nirsoft or the tool ‘CloseTheDoor’.
Thank you
PS: Sorry I took so long to answer but family business was priority.
System Idle Process, or System Process in some utilities (PID0) is not a real process in that you won’t find a file on your hard disk with that name. This pseudo process has a number of functions and one of them is dealing with closed TCP sessions.
Because of the nature of the Internet, when data is sent over a TCP connection, it doesn’t always arrive at it’s destination at the same time. Basically, a TCP packet can become fragmented and the fragments may or may not take the same path to the destination. Because of this, when a TCP session is ended by the application/process that initiated it, time has to be give for any wayward fragments to find their way home. This is why the connection isn’t simply severed and why system idle process kicks in. If I remember correctly, on Windows systems, the wait period is 120 seconds, although this can be adjusted.
Whilst it’s always a good idea to keep an eye on processes like svchost, please understand that any TCP connection is handled the same way, regardless of which application/process initiated it. Watching connections in the TIME_WAIT state, is not going to prove very enlightening 
Indeed, Radaghast, enlightened I am, now.
Thank you again for your detailed and easy to follow explanation.
cheers
+100 :-TU :-TU :-TU
Excellent detailed, comprehensible explanation. Well done!!
Ewen