There are several methods of a client communicating with a server. But why do you need a client and a server? The applications are numerous. One example would be using ssh to log into your school's cs account. In this accound they give you space and no matter where you log in, you get the same "desktop". You have access to your account and all your programs and files. It looks and behaves as if every computer you log into becomes you local machine.
In reality, the computer you are logging into is a client and it contains none of this information. It is stupid and doesn't have a mind of its own. When you interact with the client the client will always notify the server of the changes and and ask "WHAT DO I DO?!?!" the server will answer it when ever it feels like it. When it is ready it will make changes as needed and then it will tell the client what to do.
The client "mounts" your disk on to itself. It connects to the server and accesses your disk. But to get that access it needs to mount your disk onto itself. The server has the disk stored on it somewhere.
The client has a read cache but it doesn't have a write cache. It just isn't practical to have a write cache. Instead the client must have its data written directly to the disk (which is stored in the server)
After this question a questions started to brew.
I had an Interview for an Internship some time ago and they basically gave us some code and had us implement a few things. There were two applications. A client application and a server application. The server would always be running in one terminal. In another terminal a client might be running. The server is always on and it waits for a client to talk to it.
In our assignment, the client would send the server an ASCII character. The server would recieve it and it would increment it by one. (i.e. send A recieve B)
The interface of the code was nearly identical. At the time I didn't give much thought to it. I didn't have the luxury to ponder about what I had just witnessed. But as i sit in class learning about this topic I begin to wonder how one application speaks to another application.
on the highlevel, SURE it sends a message to the server. But how?
a SOCKET
Sounds rather familiar. My TA Sean Foley told me about this. I didn't much about it except that it's used to send a string.
The pieces are comming together. The socket is the middle man that allows the server and the client to communicate.
if the client and server were on the same computer then having a single SOCKET (aka fancy message buffer) would be fine.
But lets say that you computer is the server and my computer is a the client. It wouldn't make much sense to have a single socket somewhere in the middle. You would have to pretty much connect to two computers.
So instead, your computer has a socket and my computer has a socket. The socket is allows external input.
When my computer wants to talk to your computer, my computer will send its message to your computer's socket. the socket is a buffer, so eventually the your computer will notice it and take action. It will then respond and send a message to the client's socket.
end
This reminds me quite a bit about implementing the UART is embedded systems class. Although these devices could be done syncronously, it would be more practical to have a handshake protocall and ahve then opperate asyncronously. In my design of RXD, I would take in the signal and then save it into RXD's output buffer. the RXD would then tell the TXD that it has permission to read .
However, it seems that in the socket example, the buffer would be on TXD. RXD would write to TXD's buffer and then tell TXD that it should look at its buffer.
its kind of like the mailman(RXD) stopping by and giving you mail and then telling you(TXD) to check it. Maybe I should try implementing this again using this version of design.
