MVC: why do we need "controller", or when should we use this pattern?

I have read many publications about MVC, but I still can't clearly understand why do we need "controller".

I usually write applications in client-server model:

server contains all the business-logic, and it knows nothing about the gui. It does the main job, and it is as portable as possible.

client is a GUI, it binds to the server, interacts with user, sends commands from user to the server.

I like this architecture, and I can't figure out why do people really need one more medium between client and server, which seem to be controller?

UPD: simple example: assume we need to write some data logger. Data comes from the COM port, it is encoded by some protocol. Need to show received messages in a simple log window.

How would I make it:

server contains the following items:

• Data_receiver: actually receives raw data from the COM port, but it's interface, so we are able to make some another class that receives data from any other source;
• Data_decoder: takes raw data and returns resulting decoded messages, it's interface too, so we can change encoding protocol easily;
• Data_core: using instances of Data_receiver and Data_decoder, emits signals to clients.

client contains the following items:

• Appl core: creates instance of Data_receiver (the one that connects to COM port), Data_decoder and Data_core (which takes references to Data_receiver and Data_decoder instances), also creates GUI simple log window (which takes reference to Data_core);
• GUI simple log window: binds to the Data_core, i.e. listens for the signals emitted by it, and displays received data.

As I understood what I have