io.txt

著名的手机浏览器开源代码

------------------------
Handling TCP connections
------------------------

   Establishing   a   TCP  connection  requires  the  well  known
three-way handshake packet-sending sequence. Depending on network
traffic  and several other issues, significant delay can occur at
this phase.

   Dillo  handles the connection by a non blocking socket scheme.
Basically,  a socket file descriptor of AF_INET type is requested
and set to non-blocking I/O. When the DNS server has resolved the
name, the socket connection process begins by calling connect(2);
  {We use the Unix convention of identifying the manual section
   where the concept is described, in this case 
   section 2 (system calls).}
which  returns  immediately  with an EINPROGRESS error.

   After  the  connection  reaches the EINPROGRESS ``state,'' the
socket  waits in background until connection succeeds (or fails),
when  that  happens, a callback function is awaked to perform the
following  steps: set the I/O engine to send the query and expect
its answer (both in background).

   The  advantage  of  this scheme is that every required step is
quickly  done  without  blocking the browser. Finally, the socket
will generate a signal whenever I/O is possible.


----------------
Handling queries
----------------

   In  the case of a HTTP URL, queries typically translate into a
short  transmission  (the  HTTP  query)  and  a lengthy retrieval
process.  Queries  are  not  always  short though, specially when
requesting  forms  (all  the  form  data  is  attached within the
query), and also when requesting CGI programs.

   Regardless  of  query  length,  query  sending  is  handled in
background.  The thread that was initiated at TCP connecting time
has all the transmission framework already set up; at this point,
packet   sending   is   just   a   matter   of  waiting  for  the
write  signal  (G_IO_OUT) to come and then sending the data. When
the  socket  gets  ready for transmission, the data is sent using
g_io_channel_write. 


--------------
Receiving data
--------------

   Although  conceptually  similar to sending queries, retrieving
data is very different as the data received can easily exceed the
size  of  the query by many orders of magnitude (for example when
downloading  images or files). This is one of the main sources of
latency,  the  retrieval can take several seconds or even minutes
when downloading large files.

   The  data  retrieving process for a single file, that began by
setting up the expecting framework at TCP connecting time, simply
waits  for  the  read  signal  (G_IO_IN).  When  it  happens, the
low-level   I/O  engine  gets  called,  the  data  is  read  into
pre-allocated   buffers   and   the  appropriate  call-backs  are
performed.  Technically,  whenever  a G_IO_IN event is generated,
data  is  received  from  the  socket  file descriptor, using the
g_io_channel_read  read function. This iterative process finishes
upon EOF (or on an error condition).


----------------------
Closing the connection
----------------------
 
   Closing  a  TCP connection requires four data segments, not an
impressive  amount  but  twice  the round trip time, which can be
substantial.  When  data  retrieval  finishes,  socket closing is
triggered.  There's  nothing but a g_io_channel_close call on the
socket's file descriptor. This process was originally designed to
split  the  four  segment close into two partial closes, one when
query  sending  is  done  and the other when all data is in. This
scheme  is  not  currently  used  because  the  write  close also
stops the reading part.


The low-level I/O engine
------------------------

   Dillo  I/O  is carried out in the background. This is achieved
by  using  low level file descriptors and signals. Anytime a file
descriptor  shows  activity,  a  signal  is raised and the signal
handler takes care of the I/O.

   The  low-level  I/O  engine  ("I/O  engine"  from here on) was
designed  as  an  internal  abstraction layer for background file
descriptor  activity.  It  is  intended  to  be used by the cache
module  only;  higher level routines should ask the cache for its
URLs.  Every  operation  that  is  meant  to  be  carried  out in
background  should  be  handled by the I/O engine. In the case of
TCP sockets, they are created and submitted to the I/O engine for
any further processing.

   The  submitting process (client) must fill a request structure
and let the I/O engine handle the file descriptor activity, until
it  receives a call-back for finally processing the data. This is
better understood by examining the request structure:

 typedef struct {
    gint Key;              /* Primary Key (for klist) */
    gint Op;               /* IORead | IOWrite | IOWrites */
    gint FD;               /* Current File Descriptor */
    gint Flags;            /* Flag array */
    glong Status;          /* Number of bytes read, or -errno code */

    void *Buf;             /* Buffer place */
    size_t BufSize;        /* Buffer length */
    void *BufStart;        /* PRIVATE: only used inside IO.c! */

    void *ExtData;         /* External data reference (not used by IO.c) */
    void *Info;            /* CCC Info structure for this IO */
    GIOChannel *GioCh;     /* IO channel */
 } IOData_t;

   To request an I/O operation, this structure must be filled and
passed to the I/O engine.

  'Op' and 'Buf' and 'BufSize' MUST be provided.

  'ExtData' MAY be provided.

  'Status',  'FD'  and  'GioCh'  are  set  by I/O engine internal
routines. 

   When  there  is new data in the file descriptor, 'IO_callback'
gets  called  (by  glib).  Only  after  the  I/O  engine finishes
processing the data, the upper layers are notified.


The I/O engine transfer buffer
------------------------------

   The  'Buf'  and  BufSize'  fields  of  the  request  structure
provide  the transfer buffer for each operation. This buffer must
be set by the client (to increase performance by avoiding copying
data). 

   On  reads,  the client specifies the amount and where to place
the retrieved data; on writes, it specifies the amount and source
of  the  data  segment  that  is to be sent. Although this scheme
increases  complexity,  it has proven very fast and powerful. For
instance,  when  the  size  of  a document is known in advance, a
buffer for all the data can be allocated at once, eliminating the
need for multiple memory reallocations. Even more, if the size is
known  and the data transfer is taking the form of multiple small
chunks  of  data,  the  client  only  needs  to  update 'Buf' and
BufSize'  to  point  to  the  next byte in its large preallocated
reception  buffer  (by  adding  the  chunk size to 'Buf'). On the
other  hand,  if the size of the transfer isn't known in advance,
the  reception  buffer  can remain untouched until the connection
closes,  but  the  client  must  then accomplish the usual buffer
copying and reallocation.

   The  I/O  engine  also  lets  the client specify a full length
transfer  buffer  when  sending data. It doesn't matter (from the
client's  point  of  view) if the data fits in a single packet or
not,  it's  the I/O engine's job to divide it into smaller chunks
if needed and to perform the operation accordingly.


------------------------------------------
Handling multiple simultaneous connections
------------------------------------------

   The  previous sections describe the internal work for a single
connection,  the  I/O engine handles several of them in parallel.
This  is the normal downloading behavior of a web page. Normally,
after   retrieving   the   main  document  (HTML  code),  several
references  to  other files (typically images) and sometimes even
to  other  sites  (mostly advertising today) are found inside the
page.  In  order  to parse and complete the page rendering, those
other  documents  must  be  fetched  and  displayed, so it is not
uncommon  to  have  multiple  downloading  connections (every one
requiring the whole fetching process) happening at the same time.

   Even  though  socket  activity  can  reach  a hectic pace, the
browser  never  blocks.  Note also that the I/O engine is the one
that  directs  the  execution flow of the program by triggering a
call-back  chain whenever a file descriptor operation succeeds or
fails.

   A  key point for this multiple call-back chained I/O engine is
that  every  single  function  in the chain must be guaranteed to
return  quickly.  Otherwise,  the  whole  system  blocks until it
returns.


-----------
Conclusions
-----------

   Dillo is currently in alpha tests. It already shows impressive
performance,  and  its  interactive  ``feel'' is much better than
that of other web browsers.

   The modular structure of Dillo, and its reliance on GTK+ allow
it  to  be  very  small.  Not  every feature of HTML-4.0 has been
implemented  yet,  but  no  significant  problems are foreseen in
doing this.

   The  fact  that  Dillo's  central  I/O engine is written using
advanced  features  of  POSIX  and  TCP/IP  networking  makes its
performance  possible, but on the other hand this also means that
only a fraction of the interested hackers are able to work on it.

   A  simple code base is critical when trying to attract hackers
to  work  on  a  project  like this one. Using the GTK+ framework
helped  both  in  creating  the  graphical  user interface and in
handling  the  concurrency  inside the browser. By having threads
communicate  through  pipes the need for explicit synchronization
is  almost  completely  eliminated,  and  with  it  most  of  the
complexity of concurrent programming disappears.

   A  clean,  strictly  applied  layering approach based on clear
abstractions  is  vital  in  each  programming  project.  A good,
supportive framework is of much help here.