Making sequence diagrams in Eclipse is easy, thanks to the ewsd plugin.
Click to edit on WebSequenceDiagrams.com
Here's some more information on selling to large companies.
The most basic arrow type is the filled arrow.
A->B: Hello
A->B: Hello B-->A: Hi!
UML geeks will tease you if you don't make use of open arrows as well. Open arrows signify asynchronous operations.
A->>B: Hello, asyncronously!
Without further ado, here is a sequence diagram explaining how web login usually works.
You read them from top to bottom. As time increases, you depict events happening in the system, and how various parts of the system react to each other.
Be aware, however, of people that abuse sequence diagrams. You can very easily confuse people if you try to describe how long things take in a sequence diagram. Some of the most confusing diagrams that I have ever seen were trying to describe the architecture of the system. Don't do that! Sequence diagrams can only describe behaviour.
Always be aware of the primary purpose of a sequence diagram -- to explain. Here is an example of how some explanatory text along the side can make sequence diagrams more clear.
title Drop shipping With drop shipping, the retailer takes orders from a customer, but leaves responsibility for for shipping to a wholesaler or producer. Customer->Retailer: Order Retailer->Factory: Order detailsn and shipping address Factory->Customer: Ships final product option footer=none
Google is trying to make web browsers faster by inventing a new protocol called SPDY. The acronym doesn't mean anything, but it sounds similar to the word "speedy". SPDY has a few features to help download web pages faster, but it hides a lot of hidden complexity that implementors have to worry about.
The driving force behind SPDY is to save TCP setup time. Previously, to retrieve a web page, the browser would make a single connection to the web server. Then, it would request the resources one at a time. For example, it may first request the HTML page, then the scripts, and then the graphics. The problem is that the web server may take a long time to generate some parts of the web page, but it is able to serve other parts immediately. If the browser happens to request the slow parts first, all of the other resources on the web page will have to wait, and it will feel slower.
The new SPDY protocol is simply a way of allowing different resources to be sent over the same connection, in parallel. Here is how it works.
First, the browser opens a TCP connection to the server. This is when SPDY takes over, and where the first bit of complexity begins. Instead of sending an HTTP request, the browser will send a special control frame. SPDY is a framed protocol. That is, each message is prefixed by its length.
+----------------------------------+ |C| Version(15bits) | Type(16bits) | +----------------------------------+ | Flags (8) | Length (24 bits) | +----------------------------------+ | Data | +----------------------------------+
The first bit of complexity then, is how the browser knows that it may use the SPDY protocol. Maybe it is talking to one of the millions of servers that do not speak SPDY. On the server side, the server must detect that the client supports SPDY. In the beginning of an HTTP connection, the first four bytes sent will always be "HTTP". With SPDY, they consist of the version and type. The server could, perhaps, assume that the client is using SPDY if the first message is a semantically valid SPDY message. In practice, however, connections are performed over SSL which includes a negotiation step for the type of connection to be used.
However, finding out what these values are is difficult and unreliable. Your bandwidth could change from one moment to the next. At best, they are an approximation. No response is necessaryu for the hello packet.
Either the server or the client may send a PING packet. Its payload is a 32-bit number, which is expected to be unique. Whenever the client or server receives the PING packet, it should echo it back as soon as possible, with a priority higher than all other activities. This helps in calculating the round trip time. However, there are some issues with this priority scheme. What seems to be a simple protocol becomes more complex, if both the client and server need to maintain separate queues of data to be sent, with different levels of priority.
To create a stream, send SYN_STREAM control message. (This SYN_STREAM may also be used to half-close the stream) The syn_stream contains a stream id and compressed HTTP headers, and a flag indicating whether it is bidirectional or unidirectional. If it is bidirectional, the other party replies with a SYN_REPLY message, which can also contain headers.
Part of what makes SPDY speedy is that the headers are compressed. Although a general zlib compressor is used, it is initialized with a standardized string of text prior to compression. This text string contains many common HTTP headers so that it performs best when these are used.
After a stream is setup, and if the stream does not have the FINAL flag, the sender transmits the rest of the data in DATA frames. The final data frame contains a FINAL flag. Although the stream is considered done, other streams may be started.
The interesting thing is that if the browser had not used SPDY, and instead used an additional TCP connection to request the script file, it could have arrived much sooner. A single TCP connection is like highway that can clog up with traffic. All the cars ahead of you have to get to the end before you can. Having multiple TCP connections is like having an extra lane, over which higher priority traffic can arrive.
Perhaps servers can avoid this condition by carefully managing their transfer rate for all streams, and by assigning streams priorities and bandwidth. But this management comes at great complexity cost to what should be a simple protocol. Hence, implementers of have to deal with a lot of hidden complexity.
