C++: Deciphering Pointer Declarations

The right-left rule is a simple rule that allows you to interpret any declaration. It runs as follows:

Start reading the declaration from the innermost parentheses, go right, and then go left. When you encounter parentheses, the direction should be reversed. Once everything in the parentheses has been parsed, jump out of it. Continue till the whole declaration has been parsed.

One small change to the right-left rule: When you start reading the declaration for the first time, you have to start from the identifier, and not the innermost parentheses.

Take the example given in the introduction:

int * (* (*fp1) (int) ) [10];

This can be interpreted as follows:

1. Start from the variable name ————————– fp1
2. Nothing to right but ) so go left to find * ————– is a pointer
3. Jump out of parentheses and encounter (int) ——— to a function that takes an int as argument
4. Go left, find * —————————————- and returns a pointer
5. Jump put of parentheses, go right and hit [10] ——– to an array of 10
6. Go left find * —————————————– pointers to
7. Go left again, find int ——————————– ints.

Here’s another example:

int *( *( *arr[5])())();

1. Start from the variable name ——————— arr
2. Go right, find array subscript ——————— is an array of 5
3. Go left, find * ———————————– pointers
4. Jump out of parentheses, go right to find () —— to functions
5. Go left, encounter * —————————– that return pointers
6. Jump out, go right, find () ———————– to functions
7. Go left, find * ———————————– that return pointers
8. Continue left, find * —————————– to ints.

Continued reading at: http://www.codeproject.com/KB/cpp/complex_declarations.aspx#right_left_rule
More: http://www.codeproject.com/KB/cpp/PointerArticle.aspx#11

Network Archtectural Model

The TCP/IP model is basically a shorter version of the OSI model. It consists of four instead of seven layers. Despite their architectural differences, both models have interchangeable transport and network layers and their operation is based upon packet-switched technology. The diagram below indicates the differences between the two models:

 

 

• Application Layer: The Application layer deals with representation, encoding and dialog control issues. All these issues are combined together and form a single layer in the TCP/IP model whereas three distinctive layers are defined in the OSI model. 
• Host-to-Host: Host-to-Host protocol in the TCP/IP model provides more or less the same services with its equivalent Transport protocol in the OSI model. Its responsibilities include application data segmentation, transmission reliability, flow and error control. 
• Internet: Again Internet layer in TCP/IP model provides the same services as the OSIs Network layer. Their purpose is to route packets to their destination independent of the path taken. 
• Network Access: The network access layer deals with all the physical issues concerning data termination on network media. It includes all the concepts of the data link and physical layers of the OSI model for both LAN and WAN media.

For OSI Model:

Application Layer

• Serves as a window for applications to access network services.
• Handles general network access, flow control and error recovery.

Presentation Layer

• Determines the format used to exchange data among the networked computers.
• Translates data from a format from the Application layer into an intermediate format.
• Responsible for protocol conversion, data translation, data encryption, data compression, character conversion, and graphics expansion.
• Redirector operates at this level.

Session Layer

• Allows two applications running on different computers to establish use and end a connection called a Session.
• Performs name recognition and security.
• Provides synchronization by placing checkpoints in the data stream.
• Implements dialog control between communicating processes.

Transport Layer

• Responsible for packet creation.
• Provides an additional connection level beneath the Session layer.
• Ensures that packets are delivered error free, in sequence with no losses or duplications.
• Unpacks, reassembles and sends receipt of messages at the receiving end.
• Provides flow control, error handling, and solves transmission problems.

Network Layer

• Responsible for addressing messages and translating logical addresses and names into physical addresses.
• Determines the route from the source to the destination computer.
• Manages traffic such as packet switching, routing and controlling the congestion of data.

Data Link Layer

• Sends data frames from the Network layer to the Physical layer.
• Packages raw bits into frames for the Network layer at the receiving end.
• Responsible for providing error free transmission of frames through the Physical layer.

Physical Layer

• Transmits the unstructured raw bit stream over a physical medium.
• Relates the electrical, optical mechanical and functional interfaces to the cable.
• Defines how the cable is attached to the network adapter card.
• Defines data encoding and bit synchronization.

Nagle’s algorithm

Nagle’s algorithm, named after John Nagle, is a means of improving the efficiency of TCP/IP networks by reducing the number of packets that need to be sent over the network.

Nagle’s document, Congestion Control in IP/TCP Internetworks (RFC896) describes what he called the ’small packet problem’, where an application repeatedly emits data in small chunks, frequently only 1 byte in size. Since TCP packets have a 40 byte header (20 bytes for TCP, 20 bytes for IPv4), this results in a 41 byte packet for 1 byte of useful information, a huge overhead. This situation often occurs in Telnet sessions, where most keypresses generate a single byte of data which is transmitted immediately. Worse, over slow links, many such packets can be in transit at the same time, potentially leading to congestion collapse.

Nagle’s algorithm works by coalescing a number of small outgoing messages, and sending them all at once. Specifically, as long as there is a sent packet for which the sender has received no acknowledgment, the sender should keep buffering its output until it has a full packet’s worth of output, so that output can be sent all at once.

Algorithm

if there is new data to send
  if the window size >= MSS and available data is >= MSS
    send complete MSS segment now
  else
    if there is unconfirmed data still in the pipe
      enqueue data in the buffer until an acknowledge is received
    else
      send data immediately
    end if
  end if
end if

where MSS = Maximum segment size.

This algorithm interacts badly with TCP delayed acknowledgments, a feature introduced into TCP at roughly the same time in the early 1980s, but by a different group. With both algorithms enabled, applications which do two successive writes to a TCP connection, followed by a read, experience a constant delay of up to 500 milliseconds, the “ACK delay”. For this reason, TCP implementations usually provide applications with an interface to disable the Nagle algorithm. This is typically called the TCP_NODELAY option. The first major application to run into this problem was the X Window System.

The tinygram problem and silly window syndrome are sometimes confused. The tinygram problem occurs when the window is almost empty. Silly window syndrome occurs when the window is almost full.

(From Wikipedia)

Endianness

Big-Endian: MSB has the lowest address (Motoroal processors, SPARC)

Little-endian: LSB has the lowest address (x86, VAX, Z80, 6502)

+ Networks generally use big-endian order
+ English language uses big-endian order

Algorithms to determine the endianness of a machine:

//Return 0 if little-endian; 1 if big-endian
int Endianess1()
{
     int testNum = 1;
     char *ptr = (char*)&testNum;

return *ptr; //return the first byte
}

int Endianness2()
{
      union {
           int theInterger;
           char singleByte;
       } endianTest;

       endianTest.theInteger = 1;
       return endianTest.singleByte;
}