The client has to communicate somehow ... but given that this is perl, it may not be as obvious as a direct call to socket(). It could be Net::Cmd, for example. There is a huge myriad of modules on CPAN that can do socket programming - and an even larger myriad which use those lower-level modules as a base for their own abstractions.

That said, a client will generally not need to listen to a socket (non-passive FTP being the only well-known exception I'm aware of). So if you had a client/server application where both sides were listening, that would be an anomoly in my experience.

My understanding of the definition of client/server, not being a computer major in university, is that a server listens for connections, while a client initiates them. A scenario where both sides are listening kinda confuses the issue - many peer networks do this (if we serve each other, then we must be peers!). So does middleware - software that sits between clients and servers. Middleware acts as a server for the clients (waits for clients to connect to it) while acting as a client for the final server. Or, perhaps, the next server, if there is more than one level of middleware. This is not necessarily proxying as middleware is often database-based applications such that you use an application client, talking to the application server, which itself is a database client talking to the database server. So, for each context, the middleware acts as either a client, or a server, but not both (although it likely acts as both for a given transaction).

Now that I've thrown out more comp sci terms than I know, I'll leave it to someone else to answer further questions you may have on this topic.

Note also that I've probably grossly simplified these terms, so please don't quote me if you're in comp sci and about to take your midterms.