← Back to branch summary

~jan-kneschke/mysql-proxy/packet-tracking-assertions

« back to all changes in this revision

Viewing changes to doc/core.txt

  • Committer: Kay Roepke
  • Author(s): Jan Kneschke
  • Date: 2008-01-23 22:00:28 UTC
  • Revision ID: kay@mysql.com-20080123220028-hq2xqb69apa75fnx
first round on mysql-shell based on the proxy code

this is mostly a verification if the proxy-code is flexible enough to handle 
all three scenarios of: client, server and forwarding (proxy)

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/core.txt
1
 
/**
2
 
 
3
 
@page page-core Network Core
4
 
 
5
 
The Network core is built around the socket handling and brings a client and server connection
6
 
together. 
7
 
 
8
 
@see network_socket
9
 
@see network_mysqld_con
10
 
 
11
 
@section section-lifecycle Connection Life Cycle
12
 
 
13
 
Connections can be in one of several states which are basicly resembling the 4 basic phases
14
 
of the @ref protocol :
15
 
 
16
 
@li connect
17
 
@li authentification
18
 
@li query
19
 
@li disconnect
20
 
 
21
 
The plugins can change the default behaviour of the network core and impliment one of three 
22
 
basic plugins:
23
 
 
24
 
@li @ref page-plugin-admin implements only the listening side
25
 
@li client plugins implement only the connection side
26
 
@li @ref page-plugin-proxy implements both sides 
27
 
 
28
 
@subsection section-scripting Scripting
29
 
 
30
 
Most plugins implement a set of those callbacks and expose them to a scripting layer. 
31
 
 
32
 
For now the scriping is provided by Lua, a simple, fast and easy to embed scripting language.
33
 
We expose most of the internals into the scripting layer and provide modules to operate
34
 
on the data that we pass into the scripting layer
35
 
 
36
 
@section section-network-core-layer Network Core Layer
37
 
 
38
 
  The MySQL Proxy network engine is meant to handle several thousands connections at the same time. We 
39
 
want to use it for load-balancing and fail-over which means we have to handle the connections for
40
 
a larger group of MySQL backend servers nicely. We aim for 5k to 10k connections.
41
 
  Up to MySQL Proxy 0.7 we use a pure event-driven, non-blocking networking approach is described in
42
 
http://kegel.com/c10k.html#nb using libevent 1.4.x. 
43
 
  A event-driven design has a very small foot-print for idling connections: we just store the
44
 
connection state and let it wait for a event. 
45
 
 
46
 
@section section-threaded-scripting Threaded Scripting
47
 
 
48
 
Usually the scripts are small and only make simple decisions leaving most of the work to the network layer.
49
 
In 0.9 we will make the scripting layer multi-threaded allow several scripting threads at the same time,
50
 
working from a small pool threads.
51
 
 
52
 
That will allow the scripting layer to call blocking or slow functions without infecting the execution of
53
 
other connections.
54
 
 
55
 
Lifting the global plugin mutex will mean we have to handle access to global structure differently. Most 
56
 
of the access is happening on connection-level (the way we do the event-threading) and only access to
57
 
global structures like "proxy.global.*" has to synchronized. For that we will look into using Lua lanes
58
 
to send data around between independent Lua-states.
59
 
 
60
 
 
61
 
 
62
 
 
63
 
*/