Q. it seems to me that pipes, fifos, message passing, and sockets are basically the same. objectively, i mean (the seem to achieve the same thing...they just have different attributes to them). is this true. if so, we can basically use any of them for part one, right.
...if so, i'm kind of leaning towards sockets, since i think i have to use it for sure in part two. if i already implement it in part one, then it would be easier to tweek for part two.
A. You are right that pipes, FIFOs, message queues, and sockets are all pretty much the same. They are IPC types that allow processes to easily send and receive large amounts of data and they differ only in their additional attributes.
However, this does not mean that you can use any one of them for part one of this project. As the project description clearly states, you will use FIFOs for part one (and sockets for part two). Not following the explicit requirements of a project is a good way to loose points.
I chose to have you use both FIFOs and sockets in this assignment to give you experience using two different IPC types to help you appreciate the differences between them.
Q. i can't seem to reason why we would need semophones and shared memory for our project. can you tell me if i'm right.
A. You are not required to use either semaphores or shared memory in this project. However, you may choose to use either or both of them if you see a good reason for doing so.
Note that, besides the IPC that you are required to use (FIFOs and sockets for communication between clients and servers and signals for shutting down the processes), you may see a need to use other IPC to ensure that your programs work correctly. As an example, consider the following requirements in the project:
"If the client sends in a number and a zero (which indicates that a
prime has been found), the server will remove that number from the "missed
numbers" list in the file, add it to the end of a file called
schoollikelyprimes, and spawn off a child process that will
verify whether the number is prime. If the child finds that the number is
prime, it will record it in a file called schoolprimes.
Whether or not the number proves to be prime, the child process will remove
that number from the schoollikelyprimes file after checking
it. Both schoollikelyprimes and schoolprimes
will have one number per line in the file."
What happens if, while one child is checking to see if one number is
prime, another child is created by the server to check another number? Now
there is a possibility that both children will try to read from and write
to either schoollikelyprimes or schoolprimes at
the same time. This is the kind of race condition critical section that is
discussed in your book and that we have talked about in class. You will
need to find some way to safely coordinate these tasks between the
children. You could choose to use semaphores, signals, "record" locking,
or another IPC to accomplish this.
Q. I cannot get the code from the UNIX book, p2709 (client version), to compile. The error I get when trying to compile it is:
bash-2.03$ gcc -o primeathome primeathome.c Undefined first referenced symbol in file bind /var/tmp/ccsdbMkK.o inet_addr /var/tmp/ccsdbMkK.o ld: fatal: Symbol referencing errors. No output written to primeathome collect2: ld returned 1 exit status
I feel silly for asking, since I'm sure I'm overlooking something simple, but after quite some time and asking some other people, I still can't figure out what I'm doing wrong. I have all the includes from pg 270 and I've looked for small syntax errors everywhere. Well thank you for your help.
A. This is a good question, so don't feel silly for asking. It
isn't an include file that the compiler is missing, it is a library that
the link editor is missing. The clue here is that the messages refer to
"ld". If you look at the man pages for
ld, you will find that ld is the link editor and
that one of its jobs is to resolve external symbols, which it is trying to
do here. The problem is that it is failing.
Now what we need to know is why it is failing. Let us take a look at
the man page for bind, since your error message says that
bind is an undefined symbol.
% man bind
Sockets Library Functions bind(3SOCKET)
NAME
bind - bind a name to a socket
SYNOPSIS
cc [ flag ... ] file ... -lsocket -lnsl [ library ... ]
#include <sys/types.h>
#include <sys/socket.h>
int bind(int s, const struct sockaddr *name, int namelen);
...
Okay, if you typed in the code on page 270 then you have the include
files listed on the man page but what is that listed in the synopsis just
above the include files? It is the form you need to use to compile a
program that uses bind. In particular, it shows the arguments
"-lsocket" and "-lnsl" being passed to the
compiler. These arguments start with "-l" which means that
they are specifying libraries. In particular, they are specifying the
socket library and network services library (nsl) -- these define the
symbols for which ld is looking. Add these arguments to your
command line when compiling and everything should work fine.
By the way, if you want to find out more about a library with which you
are linking, you can generally (but, unfortunately, not always) use
"man libX" where X is the name of the library, to find out
more about it. So, for the nsl library, you'd give the command "man
libnsl". (For this class, however, reading and understanding these
man pages is probably not necessary.)
Q. How do we get the actual IP address of teh machine on which our
server is running. The unix system programming said to look up in the file
/etc/hosts (page 262) i am denied access to that file
A. You were right to try to look in the /etc/hosts
file. I am surprised that you were unable to access it. I have just
looked on three machines (turing, gpel1, and
gpel2) and it is readable by all users on all of them. What
machine were you on? What command did you give?
Here is what you should see if you try to display the contents of
/etc/hosts on gpel2:
% cat /etc/hosts # # Internet host table # 127.0.0.1 localhost 129.15.78.12 gpel2 loghost 129.15.78.235 turing
So, even if you can't (for some reason) access /etc/hosts,
that should give a couple of IP addresses with which to work.
Q. Since our servers should be accessible by anyone in the lab (for part 1) or on the internet (for part 2) and since we should all be using the same format for our messages, it would make sense if our group could check our work against that of other groups by having our clients try to access their servers and vice versa. Could you create an electronic communication facility for us to talk to other groups to coordinate this testing.
A. This sort of testing is a good idea. Easiest, of course, would be
to ask someone from another group who is there in the lab with you to have
one of his or her clients connect to your server or ask him or her for a
server address that you could have a client connect to. However, if you
aren't right there in the lab, some other means of communication might be
handy. I've set up a Blackboard area for this class and, with any luck,
the communication facilities should be turned on. If you are interested,
you can take a look at <http://blackboard.ou.edu/>.
You'll need to have cookies turned on in your browser.