"Client" and "Server" are just formal names for roles in situations where there is a natural asymmetry. Namely, one talks first: that's the "client".
This is how it goes in SSL: the protocol is defined to operate on a bidirectional transport medium. One of the entities talks first and sends a
ClientHello message. There is no absolute requirement that the notion of "client" and "server" that SSL uses matches the notions of "client" and "server" for the underlying connection when that connection is a TCP socket over the Internet. It just happens to be that way.
In all generality, any authentication protocol between two systems (let's call them "A" and "B") works by sending messages to each other, and one of the systems will be the first to talk. As long as both A and B know who is supposed to talk first, through some convention, then the protocol will work. The convention is easy to obtain when there is an asymmetry, e.g. the software on one machine is not the same as the software on the other. For instance, for the Web, one system uses a Web browser (e.g. Firefox) while the other uses a Web server (e.g. Apache), and standards define what either is supposed to do.
Just imagine a phone call. Someone dials the number of the other. Normal behaviour is that the person who receives the call will talk first (and say "hello"). That's exactly the concept you want. If these two talking person want to run some authentication protocol, they will have to agree on their respective roles (they can call themselves "client" and "server" if that's their wish). Using the dialer/receiver asymmetry is a natural way to bootstrap that convention. But they could use just any other convention; for instance, they could use the lexicographic order of their names (Alice is the "client" and
Bob the "server" because 'A' is before 'B' in the alphabet); or their birth date; or they may try randomly; or whatever.
That being said, in the specific case of SSL, there normally are certificates and the machine with the "server" role shows a certificate to the "client"; the "client" may also show a certificate to the "server". Certificates prove bindings between keys and identities, but this has any value only if the identity has some meaning. I.e., when the server shows its certificate to the client, the important point is that the server's certificate contains the server name, and the client expects a very specific server name (the one from the URL). Similarly, when the client shows its certificate to the server, this makes some useful authentication only if the server can find in the certificate some notion of identity which makes sense for him.
A more interesting situation with SSL is SRP: with this variant, no certificate at all. Client and server authenticate each other relatively to their knowledge of a shared secret (a password). They still must agree on who talks first ! And there is an extra point, which is the entity with the "server" role does not need to store the password itself, only a hashed version thereof (with some algebraic structure). In that sense, who assumes the "server" role is not completely arbitrary with regards to security: even in a mutual authentication protocol, security characteristics achieved on both sides may differ.