Web browsing traffic model

A new traffic model for ns-3, as announced in the mailing list [1]. The patch contains the following:

- Two new applications: `HttpClient` and `HttpServer`.

- `HttpVariables` for all sort of randomization in the model, e.g., packet sizes, off times, etc.

- `HttpTag` to be used on each transmitted packet to differentiate main and embedded objects and to allow the model to compute delays.

- A new test suite `http-client-server`.

- Typical helper classes `HttpClientHelper` and `HttpServerHelper`.

- Some histogram figures to illustrate the distributions of the random number generators in the model. They are included in the Doxygen documentation.

[1] http://mailman.isi.edu/pipermail/ns-developers/2015-April/012668.html

[Tommaso Pecorella, 2016-04-03 23:08:13]

The code is very good, but I didn't expect anything less.
I have some doubts about the expected behaviour tho.

I know that this is an HTTP 1.1 - like generator, but it seems that the embedded
objects are send one by one, with the following one sent only when the previous
one has been transmitted.

Now, this has multiple problems.
1) even if you use a L7 buffer, unless you poke the socket you don't know if the
socket did successfully sent the previous data. I think this is done in the
code.
2) this isn't really what happens in HTTP...

Even if we don't want to consider parallel streams, the object interaction
should be: 1) client requests a main object / receives it, 2) parsing time, 3)
Client requests all the embedded objects. Citing W3C.

Pipelining
Although HTTP/1.1 encourages the transmission of multiple requests over a single
TCP connection, each request must still be sent in one contiguous message, and a
server must send responses (on a given connection) in the order that it received
the corresponding requests. However, a client need not wait to receive the
response for one request before sending another request on the same connection.
In fact, a client could send an arbitrarily large number of requests over a TCP
connection before receiving any of the responses.

Non-pipelining is possible, but it must be documented.

Last comment... the documentation in ReST please. I know that other applications
don't have it, but it's a good moment to start it.

https://codereview.appspot.com/233780043/diff/1/src/applications/model/http-c...
File src/applications/model/http-client.cc (right):

https://codereview.appspot.com/233780043/diff/1/src/applications/model/http-c...
src/applications/model/http-client.cc:456: "Packet size shall not be larger than
MTU size.");
This assert is strange. Mind to explain ?
What if the user changes the application params ?

https://codereview.appspot.com/233780043/diff/1/src/applications/model/http-c...
src/applications/model/http-client.cc:503: "Packet size shall not be larger than
MTU size.");
Same observation as before.

https://codereview.appspot.com/233780043/diff/1/src/applications/model/http-c...
src/applications/model/http-client.cc:675: HttpTag httpTag =
HttpTag::ReadTagFromPacket (packet);
In a "real" HTTP message the message size is coded differently (and, to be
honest, in a completely crazy way).
Please add a huge note that the use of a tag is to avoid the burden of doing a
real message parser.

About the use of tags in particular, I would have used a TLV instead, or another
type of coding.
The risk with tags is that in the same packets you have two (or more) different
tags of the same kind. This could happen if you chain small objects - boundaries
will not be respected and you could end with a packet with the end of an object
and the start of another one.

Speaking of, this could happen in any case, unless you're sure to flush the TCP
Tx buffers before sending more bytes, and you can't be sure that Tx buffers are
flushed.
As a consequence, you have to consider this case, sorry.

https://codereview.appspot.com/233780043/diff/1/src/applications/model/http-c...
File src/applications/model/http-client.h (right):

https://codereview.appspot.com/233780043/diff/1/src/applications/model/http-c...
src/applications/model/http-client.h:77: * 1. Upon start, it opens a connection
to the destination web server
Use Doxygen lists please (in oder to keep the formatting right)

https://codereview.appspot.com/233780043/diff/1/src/applications/model/http-c...
src/applications/model/http-client.h:97: * server is maintained and used for
transmitting and receiving all objects.
I guess you're referring to HTTP 1.1 - nevertheless, it's good to be explicit
(especially since HTTP 2.0 is standardized).

https://codereview.appspot.com/233780043/diff/1/src/applications/model/http-s...
File src/applications/model/http-server.cc (right):

https://codereview.appspot.com/233780043/diff/1/src/applications/model/http-s...
src/applications/model/http-server.cc:855: << " until the previous content has
been completely sent.");
This is a quite strong assumption (and behaviour too)

https://codereview.appspot.com/233780043/diff/1/src/applications/model/http-t...
File src/applications/model/http-tag.cc (right):

https://codereview.appspot.com/233780043/diff/1/src/applications/model/http-t...
src/applications/model/http-tag.cc:46: HttpTag::IsFoundInPacket (Ptr<const
Packet> packet)
Unnecessary - it is equivalent to 
bool ns3::Packet::FindFirstMatchingByteTag

https://codereview.appspot.com/233780043/diff/1/src/applications/model/http-t...
src/applications/model/http-tag.cc:67: HttpTag::ReadTagFromPacket (Ptr<const
Packet> packet)
As for the above function, this is unnecessary. Its functionality is already in 
bool ns3::Packet::FindFirstMatchingByteTag

https://codereview.appspot.com/233780043/diff/1/src/applications/model/http-t...
File src/applications/model/http-tag.h (right):

https://codereview.appspot.com/233780043/diff/1/src/applications/model/http-t...
src/applications/model/http-tag.h:145: uint16_t m_contentType;   ///< Content
type field in integer format.
The correct syntax is "//!<"
"///" is a shortcut for a doxygen comment on the *following* line.

[Tom Henderson, 2016-12-09 14:39:13]

This review and patch set has been superseded by:

https://codereview.appspot.com/314810043/