CSC323 2010S Software Design


Sechrest, Stuart (n.d.). An Introductory 4.4 BSD Interprocess Communications Tutorial. Available online at

Why would two way communication through a single pipe be complicated if both parent and child have the address of the receiving and sending end?

Why doesn't the UNIX domain allow for communication between different machines?

I'm having difficulty analyzing the process diagrams (the ones with the circles with lines going down to list-boxes), mainly with their interactions with the list-boxes.

This article seems to indicate that there is a significant amount of similarity between UNIX interprocess communication and internet intermachine communication. Am I right about this or am I just reading this completely wrong?

I don't really understand the significance of the UNIX 4.2BSD release's ability to communicate within a single machine via pipes. A basic function of computers has always been to communicate throughout a single machine. What made this development so important, aside from its eventual contribution to communication between multiple machines?

Both in lecture and in the reading the datagram type of communication has been described as "unreliable". What is it about datagrams that causes this? I do not see why the data would "disappear" when sent. Even if it were to disappear, why would streams not suffer the same problems?

How often are each of these methods used? My current understanding of networking is that the lowest level of data sent are packets. Are these packets equivalent to datagrams? Our ability to use streams implies that they are not. Is the data transmitted through the stream packed into packets in the same way datagrams are?

On page 20-2, the authors discuss descriptor table indicies as storage for input/output destinations. How are these tables created, accessed, and modified in memory to specify I/O?

In modern networking, are streams and datagrams still the primary tools? If not, what has replaced them?


On page 20-7, the authors define a protocol as a "a set of rules, data formats and conventions that regulate the transfer of data between participants in the communication." Would these be protocols such as IP and TCP (the Internet Protocol Suite)? What exactly comprises a protocol? What are some other protocols used in modern communication?

You've suggested that a server or client might append characters to the end of a message to ensure that the recipient realizes the end of the message. Would you be able to use the same character for number data, string data, and character/byte data? I realize it's all converted when it's being sent, but is there any kind of checking done to ensure that the content of a message is all of the same format? Would this checking object to a universal end-of-message code in some cases? I suppose that means we should choose our end-of-message symbols carefully.

The paper points out that send() and recv() support "peeking" to see how large the next message is. Is this the usual solution to receiving messages of arbitrary length - peek to see the size of the message, and then receive it? If so, is it still necessary to include end-of-message codes? If a server or client didn't know whether its intended recipient used peeking or simply received until an end-of-message code, wouldn't that result in junk being sent sometimes?

OS Issues

The paper makes signals from the operating system sound important enough that programmers need not explicitly listen for them. By what means are they transmitted from the operating system to the program? What can the OS do to programs that ignore signals, if that is possible?

What is an inode? Is it physically written to disk or is it maintained in memory as a reference to something that could be a file?

In my limited experience with network programming in C, the use of forks presented serious risks. Have modern languages implemented them in a less hazardous way? What are/would be any negative consequences of doing so?

Forks are more a systems programming issue than a network programming issue. What risks did you observe?

Disclaimer: I usually create these pages on the fly, which means that I rarely proofread them and they may contain bad grammar and incorrect details. It also means that I tend to update them regularly (see the history for more details). Feel free to contact me with any suggestions for changes.

This document was generated by Siteweaver on Thu Apr 8 12:52:17 2010.
The source to the document was last modified on Thu Apr 8 12:51:55 2010.
This document may be found at

You may wish to validate this document's HTML ; Valid CSS! ; Creative Commons License

Samuel A. Rebelsky,

Copyright © 2010 Samuel A. Rebelsky. This work is licensed under a Creative Commons Attribution-NonCommercial 2.5 License. To view a copy of this license, visit or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.