The port a process 'listens' on is how a client will make it's initial connection, i.e. a web server listens (by default anyway) on port 80. When a client needs to communicate with the server it will make it's initial connection to the server on this port.
As part of the connection handshake the client and server will negotiate another set of port numbers to communicate on and these are the ports used for the remainder of the conversation.
These 'negotiated' port numbers are not however treated as new connections as they are part of the existing connection that happened to start on port 80 - therefore they are not blocked by your firewall etc. as they are not 'incoming requests'.
The scenario I suggested above of using seperate threads for each connection will work but this can cause scalability issues if the number of connections gets large as you will end up with a large number of threads, a lot of which will be idle for large portions of the time.
In this scenario rather than a 'one client = one thread' model you would find using async sockets more scalable as you would only need to allocate resources as and when data arrives.