2009年4月1日星期三

dist-sys-susx.ac.uk



























source: http://www.cogs.susx.ac.uk/courses/dist-sys/node1.html



2.1 Introduction


Main Points

  • What we are going to cover
  • What distributed systems are
  • What characteristics well-designed systems have


2.1.1 Course Outline




What are we going to do?

  • 1 lectures on computer communications and networks and loosely
    coupled systems, revising material from the Multimedia
    Communications Technology course. The Postgraduate course will get
    an additional two hours in their seminar slot.
  • 5 lectures on Remote Procedure Call, distributed objects and
    classic distributed systems such as NFS
  • 3 lectures on integrating distributed systems through the web,
    content distribution networks and Peer to Peer computing.
  • 5 lectures on closely coupled systems for distributed
    transactions
  • 1 lecture on recent advances in networks and distributed
    systems

2.1.2 What's a Distributed System




A distributed system: physically separate computers working
together



  • Cheaper and easier to build lots of simple computers
  • Easier to add power incrementally
  • Machines may necessarily be remote, but system should work together
  • Higher availability - one computer crashes, others carry on
    working
  • Better reliability - store data in multiple locations
  • More security - each piece easier to secure to right level.


2.1.2.1 The real world...


In real life, can get:

  • Worse availability - every machine must be up. ``A distributed
    system is one where some machine you've never heard of fails and
    prevents you from working''
  • Worse reliability
  • Worse security

Problem: Coordination is more difficult because multiple
people involved, and communication is over network.


Your Task: What are the distributed interactions when you
login at an x-terminal?


2.1.2.2 Interactions at an X terminal




Simplified interactions




Image login


2.1.3 Example Distributed Systems




Electronic MailMail delivered to remote mailbox. Requires
global name space to identify users, transport mechanisms to get
mail to mailbox
Distributed Information - WWWRemote information hidden below
hypertext browser. Caching and other features operate transparently
Distributed File SystemFiles stored on many machines,
generally not machine you're working on. Files accessed
transparently by OS knowing they're remote and doing remote
operations on them such as read and write e.g. Network File System
(NFS)
Trading Floor SystemBids made, stocks sold, screens updated.

2.1.3.1 Network assumptions



  1. The network is reliable
  2. Latency is zero
  3. Bandwidth is infinite
  4. The network is secure
  5. Topology doesn't change
  6. There is one administrator
  7. Transport cost is zero
  8. The network is homogeneous

(Source:The Eight Fallacies of Distributed Computing -
Peter Deutsch


2.1.4 What do we want from a Distributed System?





  1. Resource Sharing
  2. Openness
  3. Concurrency
  4. Scalability
  5. Fault Tolerance
  6. Transparency

Your Task: order the importance of each of these features for the
example systems in the previous slide.


2.1.5 Elements of a Distributed System


Another way to view a system...

  • Communications system
  • Messages
  • Machines
  • Processes on Machines
  • Programs
  • People


2.1.6 Conclusion



  • Its difficult to design a good distributed system: there are a
    lot of problems in getting ``good'' characteristics, not the least of
    which is people
  • Over the next ten weeks you will gain some insight into how to
    design a good distributed system.


2.2 Bits and Bytes


Main Points

  • Bits and Bytes
  • Kilo, Mega, Giga, Tera
  • Memory, Packets and Bit Manipulation




2.2.1 Bits, Bytes, Integers etc





  • All data in computers is held as a sequence of ones and zeros.
  • A number is represented as the base 2 number held in some
    pre-ordained fixed number of bits
  • Almost all other data is represented as various sets of
    numbers.
  • A byte is 8 bits sequenced together - what is the
    maximum number?
  • Integers (in Java and most other languages nowadays)
    are 32 bits long - what is the maximum number?


2.2.2 Prefices



  • In communications we talk often about throughput in
    bits/second, or moving files of some particular size. We use
    magnitude prefices for convenience
    kilo1000 x

    mega1000000 x

    giga
    109 x

    tera
    1012 x

  • There is often confusion as to whether a kilobyte is 1000 or
    1024 bytes. When dealing with processor architectures, its
    generally 1024. When dealing with communications, its
    generally 1000. State assumptions if it is not obvious from
    context.



2.2.3 Memory and Packets



  • A computer stores data as bits in memory.
  • When it wants to send this data to another computer, it copies
    the bits into the memory of the communications device.
  • The communications device sends the bits through the network
    to the other machine (we'll cover the details of this in the
    coming week).
  • The other machine's communication device places the bits
    into memory which the other machine can access.
  • The tricky bits come in ensuring that both machines
    interpret the bits correctly.

2.2.4 Bit Manipulation



  • Not only must the data be sent, but accompnying information
    allowing the computers to interpret the context of the data.
  • Communications software must be able to pick out arbitrary bits
    from an opaque bit sequence and interpret their meaning.
  • We do this using bitwise operations - and, or, exclusive or,
    negation    .


2.3 Foundations of Distributed Systems


Aim: How do we send messages between computers across a network?
Physical Concepts:Bandwidth, Latency
Packet Concepts:Data, Headers
Routing Concepts:Shared Media, Switches and Routing Tables,
Routing Protocols

For more detailed notes, see Dan Chalmers' Multimedia Communications Technology notes in http://www.informatics.sussex.ac.uk/courses/mct/.

2.3.1 Physical Concepts


What is a message?

  • A piece of information which needs to move from one process to
    each other eg a request to open a file, an email message, the
    results of a remote print request.


For the network, this is a just a sequence of bits in memory.


Need to communicate this sequence of bits across communications
system to other host.


Signal to other side whether each bit in sequence is
0 or 1.


To communicate, need each end to each access a common substrate, and
then for the sender to change the value of a physical characteristic
of the substrate.


Examples - voltage level of a piece of wire, light level in optical
fibre, frequency of radio wave in air


2.3.1.1 Signal characteristics




If physical characteristic has two levels then signal is binary.


If it has more than one level, can encode a number of bits to each
level.


If 4 levels, then level 0 = 00, level 1 = 01, level 2 = 10, level 3 =
11


If 8 levels, how many bits can be encoded?


2.3.1.2 Bandwidth




Adjusting the level at one end, and recognising the level has changed
at the other takes finite time.


The finite time limits the speed at which bits can be signalled.


The rate of signalling is the bandwidth, measured in bits per second.


If it takes 20 microseconds to raise the voltage on a wire, and 10
milliseconds to recognise the new level, what is the possible
bandwidth if there are two levels? Eight levels?


2.3.1.3 Noise and errors


Can we get infinite bandwidth by increasing the number of levels?


No, since noise makes it impossible to correctly distinguish level.


Noise is random changes in the physical characteristic to which all
physical phenomena are prone.


Always some probability that level will be misinterpreted.


Always some probability of error in message.


Goal of communications engineers is to make this probabilty as low as
necessary.


2.3.1.4 Latency


Does signal propagate along wire infinitely fast?


No, limit to speed of propagation of light. Hence described
as propagation delay.


Latency is time taken for signal to travel from one end of
communication system to destination.


Since communication system may reconstruct message at intermediate
points, time taken to reconstruct message is also part of latency.
Known as switching delay


Your Task: Describe the bandwidth, propagation delay and
switching delay in a game of chinese whispers.

2.3.2 Packets


If there is an error in a message, how is it detected and rectified?



  1. Compute a checksum over the message
  2. send the checksum with the message
  3. Calculate a new checksum over the received message
  4. Compare the checksums - if different, then message is in error
  5. Ask for the message to be resent

Probability of error rises with length of message,


Thus message sent in separate lumps with maximum number of bits
per lump, known as packets.


If the message fits in one packet, good. Otherwise message is in many
packets.

2.3.2.1 Addressing




How do we direct the packet to correct recipient(s)?



  • Put header bits on front of packet, analogous to address and
    other information on envelope in postal system. Add source of
    packet to allow returns
  • Destination | Source | Packet body
  • If destination and source share the same physical medium, then
    destination can listen for its own address (ethernet, wireless,
    single point to point link)
  • If they don't share the same LAN, we use routing


2.3.2.2 Names, addresses and routes




NameIdentifier of object eg Ian Wakeman, Mum
AddressLocation of object eg Rm 4C6, COGS
RouteHow to get there from here - ``turn left, first right and
up stairs, first door on left''



Internet: Name is a Domain Name, such as www.cogs.susx.ac.uk. More
later.


To get packet through network, turn name into address by asking Domain
Name Service (DNS).


Place address in packet header and hand to nearest router.


Router locates MAC address corresponding to IP address, if they're on
the same LAN.

2.3.2.3 Indirect Addressing






\includegraphics{figs/indirect-addresses}

2.3.2.4 Architecture of a switch




\includegraphics{figs/switch}




A switch is a specialised computer. Can turn a PC into a router,
using free software.

  1. A packet arrives on a link
  2. The switch gets the destination of the packet from the packet
    header
  3. The switch looks up the destination in a routing table in
    memory and discovers the output link
  4. The switch queues the packet to be sent on the output link

2.3.2.5 Distributed Routing Table Maintenance


The situation:

  • People are network administrators (and end users)
  • Communication systems are links (possibly multipoint)
  • Machines are switches
  • Messages may be lost

The problem: Given an address, how does a router know which output
link to send the packet on?


Choices:

  1. Packet could contain list of all output links - source routing.
    Requires source to lookup and determine route. May be good thing.
  2. Router could look up address in local routing table, and send out of
    corresponding link. If not in table, send out default link.



How do we construct tables? Could install entries by hand, known as
static routing.

But

  • Limited to entries people know about.
  • Unable to ensure consistency and absence of loops
  • Unable to respond to changing topology, sharks gnawing through undersea
    cables etc.
  • Internet has no centralised authority



So we use distributed routing algorithm


2.3.2.6 Distance Vector Routing



  1. Each switch knows its own address
  2. Each link has''cost'', such as a value of 1 per link, or measure
    of delay.
  3. Each switch starts out with distance vector, consisting of 0 for
    itself, and infinity for everyone else
  4. Switches exchange distance vectors with neighbour switches, and
    whenever info changes
  5. Switch saves most recent vector from neighbours
  6. Switch calculates own distance vector by examining cost from
    neighbour and adding cost of link to neighbour
  7. Use link with minimum cost to destination as link to route out.

Examples include RIP and BGP.


2.3.2.7 Link State Routing



  1. Each switch knows addresses that are direct neighbours
  2. Switch constructs packets saying who are neighbours - link
    state packets    .
  3. Link state packets flooded to all other switches
  4. Switch constructs complete graph using most recent link state
    packets from all other switches
  5. Use Dijkstra shortest path to figure out routing table.



Examples include OSPF.

2.3.3 Conclusion: Network Properties


Packet Switched Networks present certain fundamental problems to the distributed systems programmer:

  • Whilst switches converge on a consistent set of routes, packets
    will bounce around in the network, and suffer delays or get dropped.
  • Switches shared with other packets, therefore get queues.
  • Total latency is therefore variable.
  • Loss rate is variable (noise, available switch buffers).
  • Queue size management (aka congestion control) changes the bandwidth available to machines. Therefore bandwidth is variable.

2.8 Computer Security: Why you should never trust a
computer system




Goal: Prevent Misuse of computers

  • Definitions
  • Authentication
  • Private and Public Key Encryption
  • Access Control and Capabilities
  • Enforcement of security policies
  • Examples of Security Problems


2.8.1 Definitions




Types of Misuse

  • Accidental
  • Intentional



Protection is to prevent either accidental or intentional misuse


Security is to prevent intentional misuse


Three pieces to security

AuthenticationWho user is
AuthorisationWho is allowed to do what
EnforcementEnsure that people only do what they are allowed to do

A loophole in any of these can cause problem eg

  1. Log in as super-user
  2. Log in as anyone, do anything
  3. Can you trust software to make decisions about 1 and 2?


2.8.2 Authentication


Common approach: Passwords. Shared secret between two parties. Since
only I know password, machine can assume it is me.


Problem 1 system must keep copy of secret, to check against
password. What if malicious user gains access to this list of
passwords?


Encryption Transformation on data that is difficult to
reverse - in particular, secure digest functions.

2.8.2.1 Secure Digest Functions


A secure digest function h = H(M) has the following properties:

  1. Given M, is is easy to compute h.
  2. Given h, it is hard to compute M.
  3. Given M, it is hard to compute M' such that
    H(M) = H(M')



For example: Unix /etc/passwd file


Password
$ \rightarrow$ one way transform
$ \rightarrow$ encrypted
password


System stores only encrypted version, so ok if someone reads the file.
When you type in password, system encrypts password and compares
against the stored encrypted versions.


Over the years, password protection has evolved from DES, using a
well-known string as the input data, and the password as the key,
through to MD5 to SHA-1.


2.8.2.2 Passwords as Human Factors Problem




Passwords must be long and obscure.


Paradox: short passwords are easy to crack, but long
ones, people write down


Improving technology means we have to use longer passwords. Consider
that unix initially required only lowercase 5 letter passwords


How long for an exhaustive search?
265 = 10, 000, 000

  • In 1975, 10 ms to check a password
    $ \rightarrow$ 1 day
  • In 2003, 0.00001 ms to check a password
    $ \rightarrow$ 0.1 second



Most people choose even simpler passwords such as English words - it takes
even less time to check for all words in a dictionary.


2.8.2.3 Some solutions





  1. Extend everyone's password with a unique number (stored in
    passwd file). Can't crack multiple passwords at a time.
  2. Require more complex passwords, eg 7 letter with lower, upper,
    number and special
    707 $ \approx$ 8000 billion, or 1 day. But
    people pick common patterns eg 6 lower case plus number.
  3. Make it take a long time to check each password. For example,
    delay every login attempt by 1 second.
  4. Assign long passwords. Give everyone a calculator or smart card
    to carry around to remember password, with PIN to activate. Need
    physical theft to steal card.



Problem 3 Can you trust the encryption algorithm? Recent
example: techniques thought to be safe such as DES, have back doors
(intentional or unintentional). If there is a back door, you don't
need to do complete exhaustive search.


2.8.3 Authentication in distributed systems: Private Key Encryption




In distributed systems, the network between the machine on which the
password is typed and the machine the password is authenticating on is
accessible to everyone.


Two roles for encryption:

  1. Authentication - do we share the same secret?
  2. Secrecy - I don't want anyone to know this data (eg medical
    records)



Use an encryption algorithm that can easily be reversed given the
correct key, and difficult to reverse without the key


\includegraphics{figs/private}



  • From cipher text, can't decode without password.
  • From plain text and cipher text, can't derive password.
  • As long as the password stays secret, we get both secrecy and
    authentication.

2.8.3.1 Symmetric Encryption


Symmetric encryptions use exclusive ors, addition, multiplication,
shifts and transpositions, all of which are fast on modern processors.
DESThe Data Encryption Standard (DES) was released in 1977.
The 56 bit key is too weak for most uses now, and instead, 3DES or
triple DES is used, which has 128 bit keys.
IDEAThe International Data Encryption Algorithm has 128 bit
keys, and has proven strong against a large body of analysis.
AESThe US based NIST has defined a new encryption algorithm
based on Rijndael, which offers 128, 192 or 256 bit keys.


2.8.3.2 Authentication Server - Kerberos Operation




The server keeps a list of passwords, provides a way for two parties,
A, B to talk to each other, as long as they trust the server.


Notation: Kxy is a key for talking between x and y. (..)$ \wedge$K means
encrypt message (..) with key K.


Simplistic overview:

  • A asks server for key:


    A
    $ \rightarrow$ S (Hi! I'd like a key for A,B)



  • Server gives back special ``session'' key encrypted in A's key, along
    with ticket to give to B:


    S
    $ \rightarrow$ A (Use Kab (This is A! Use Kab)$ \wedge$Ksb)$ \wedge$Ksa



  • A gives B the ticket:


    A
    $ \rightarrow$ B ((This is A! Use Kab)$ \wedge$Ksb


Details: add in timestamps to limit how long each key exists, use
single use authenticators so that clients are sure of server
identities, and to prevent machine replaying messages later.


Also have to include encrypted checksums to prevent malicious user
inserting garbage into message.


2.8.4 Public Key Encryption




Public key encryption is a much slower alternative to private key;
separates authentication from secrecy.


Each key is a pair K,K-1


With private key: (text)$ \wedge$K$ \wedge$K = text


With public key:

  • (text)$ \wedge$K$ \wedge$K-1 = text,
    but (text)$ \wedge$K$ \wedge$K $ \neq$ text



  • (text)$ \wedge$K-1$ \wedge$K = text,
    but (text)$ \wedge$K-1$ \wedge$K-1 $ \neq$ text



Can't derive K from K-1, or vice versa

2.8.4.1 Public key directory




Idea: K is kept secret, K-1 made public, such as public directory


For example: (I'm Ian)$ \wedge$K Everyone can read it, but only I
could have sent it (authentication).


(Hi!)$ \wedge$K-1 Anyone can send it but only I can read it
(secrecy).


((I'm Ian)$ \wedge$K Hi!)$ \wedge$K'-1


On first glance, only I can send it, only you can read it.
What's wrong with this assumption?


Problem: How do you trust the dictionary of public keys? Maybe
somebody lied to you in giving you a key.

2.8.5 Secure Socket Layer





  • Provides a techniques for data sent over a TCP connection to be
    encrypted.
  • Uses public key technology to agree upon a key, then 3DES or
    whatever to encrypt the session.
  • Data encrypted in blocks, optionally with compression first.
  • Used in http as https, and for telnet, ftp etc.

2.8.5.1 SSL handshake protocol




\includegraphics{figs/ssl}


2.8.6 Authorisation




Who can do what...


Access control matrix: formalisation of all the permissions in the
system







































objectsfile1file2file3...
users    
Arwr  
B rw  
C  r 
...    



For example, one box represents C can read file3


Potentially huge number of users and objects, so impractical to store
all of these.


2.8.6.1 Approaches to authorisation





  1. Access control list - store all permissions for all users with
    each object


    Still might be large number of users. Unix addresses by having rwx
    for user group world. Recent systems provide way of specifying
    groups of users and permissions for each group

  2. Capability list - each process stores tickets for the objects it
    can operate on.


2.8.6.2 Digital Rights Management





  • Digital content is produced by people earning a living, and they
    wish to protect their investment
  • Digital Rights Management is the catchall term for the
    technologies controlling the use of digital content.
  • Two main approaches:
    Containmentin which the content is wrapped is an encrypted
    shell, so that users have to prove their capability of
    using the content through knowledge of the key.

    Watermarkingwhere the content is marked so that devices know
    that the data is protected.


  • The problem is how to enforce the checking of
    capabilities and enforce the no circumvention requirement.


2.8.7 Enforcement




Enforcer is the program that checks passwords, access control lists,
etc


Any bug in enforcer means way for malicious user to gain ability to do
anything


In Unix, superuser has all the powers of the Unix kernel - can do
anything. Because of coarse-grained access control, lots of stuff has
to run as superuser to work. If bug in any program, you're in
trouble.


Paradox:

  1. make enforcer as small as possible - easier to get correct, but
    simple minded protection model (more programs have high privilege).
  2. fancy protection - only minimal privilege, but hard to get
    right.

2.8.8 Trusted Computing Platform




Question: How do we ensure no software transgresses digital
rights?


Answer: By only allowing approved software to have access to
the data.



  • The basic computer and operating system must be running
    validated software.
  • There must be an untamperable part of the computer/OS that can
    hold keys and hand over only to validated software.
  • The untamperable part of the computer is the Fritz chip, a
    co-processor which holds a unique certificate that it is running
    some validated code

2.9 Names and Naming Services


2.9.1 Main Points





  • Use of names
  • Structure of names
  • Name Services
  • Domain Name Service (DNS) - The Internet Name Service



Definitions:-

Names- what its called
Address- where it is
Route- how to get there


2.9.2 Why names?




Object Identificationa service or resource we want to use, eg
a filename, a telecommunications provider, a person
Allow SharingCommunicating processes can pass names and thus
share resources
Location IndependenceIf we separate the name from the address,
can migrate object transparently
SecurityIf large number of possible names, knowing the name of
the object means that it must explicitly have been passed. If
entire system constructed so that names are passed with
authorisation then knowing name means chain of trust to allow
access to object.


2.9.3 What does one do with names?



  • Use as arguments to functions, eg to call a service
  • Create names. If an object comes into creation it must be
    named. Name should meet rules for system, eg be unique, therefore
    naming authority (possibly object) must keep track of what names it
    has allocated
  • Delete names. When an object disappears from the system, at
    some point may wish to delete name and allow re-use.


2.9.4 What's a name?





  • Part of the design space for any distributed system is how to
    construct the name.
  • Choice of design has ramifications for design of rest of system
    and performance of service.


2.9.4.1 Unique Identifier





  • Unique Identifier (UID) aka flat names, primitive names.
  • No internal structure, just string of bits.
  • Only use is comparison against other UIDs eg for lookup in table
    containing information on named object.
  • Provide location independence and uniformity
  • But Difficult to name different versions of the same
    object eg Distributed systems edition 1 vs Distributed Systems
    edition 2. Real objects have relationships to each other - useful
    to reflect in naming practice
  • Difficult to discover address from name - need to search entire
    name space


2.9.5 Partitioned names


Add partition structure to name to enable some function to be
more efficient, typically location and name allocation


\includegraphics{figs/dns}



  • Domain Name Service (DNS) name - unix.rn.informatics.scitech.sussex.ac.uk.
    Each part of name comes from flat name space. Division of name space
    and possible objects into smaller space. "uk" reduces objects to
    those within the uk, "ac" to those administered by academic
    networks, and so on.



  • When allocating names, simply add to lowest part of partition.
    Low risk of collision, since small number of other objects, all
    administered by same authority



  • When looking up name, can guess where information will reside.


2.9.6 Descriptive names



  • Necessary to have a unique name.



  • But useful to name objects in different ways, such as by service
    they offer eg Postman Pat, John of Gwent, www.informatics.sussex.ac.uk.



  • Create name using attributes of object.



  • Note that objects can therefore have multiple names, not all of
    which are unique



  • Choice of name structure depends on system. DNS chooses
    partition according to administration of creation, with aliases to
    allow naming by service eg ftp.informatics.sussex.ac.uk is also
    doc-sun.rn.informatics.scitech.sussex.ac.uk


2.9.7 Object Location from name - broadcast



  • Ask all possible objects within the system if they respond to
    that name. Can be efficient if network supports broadcast eg
    Ethernet and other LANs.



  • Equivalent to distributing name table across all objects,
    objects storing names referring to them.



  • Only want positive responses - all responses would generate a
    lot of traffic.



  • Scaling problem when move into wide area.

    • Greater number of hosts imply greater probability of failure



    • Broadcasts consume higher proportion of bandwidth, made worse
      due to higher failures needing more location requests




  • Broadcast used only on small LAN based systems (and in initial
    location of directory)


2.9.8 Location through database



  • Keep information about object in a table, indexed by a name. Location
    is just another piece of information.



  • In DNS, table is stored as {name,attribute} pairing, in a resource record



  • If database centralised, then

    • Whole system fails if database machine fails
    • Database machine acts as bottleneck for performance of system as
      whole
    • In wide area systems, authority should be shared amongst
      controlling organisations



    So name information usually distributed.


2.9.9 Distributed Name Servers


Parts of the name table are distributed to different servers eg. in
Domain Name Service, servers are allocated portions of the name space
below certain domains such as the root, ac.uk, susx.ac.uk


Names can be partitioned between servers based on

algorithmic clusteringeg apply well-known hash function on name to map to server. May
result in server being remote from object. Only technique for UIDs
structural clusteringif name is structured, use structure to designate names to particular server, such as in DNS
attribute clusteringif names are constructed using attributes, then servers take responsibility for certain attributes.


2.9.10 Availability and performance


If a single server is responsible for name space, there is still single
point of failure, and a performance bottleneck.


Most systems therefore

  • Replicate name list to other servers. Also increases
    performance for heavily accessed parts of name space eg secondary
    servers in DNS
  • Cache information received by lookup. No need to repeat lookup
    if asked for same information again. Increases performance.
    Implemented in both client side and server (in recursive calls) in
    DNS.



If information is cached, how do we know when its invalid? May
attempt to use inconsistent information.


2.9.11 Maintaining consistency for distributed name services


Alleviated by following features of some distributed systems

  • In most systems objects change slowly, so names live for a long
    time, and are created infrequently
  • If address of an object is wrong, it causes an error. Address user
    can recover if it assumes one of the possible problems is inconsistent
    information.
  • Obsolete information can be fixed by addressed object leaving
    redirection pointers. Equivalent to leaving a forwarding address to new home.



However, there are always systems which break these assumptions eg
highly dynamic distributed object system, creating lots of objects and
names and deleting lots of names.


2.9.12 Client and Name server interaction.



  • Hidden behind RPC interface.



  • Client knows of server to ask (either installed in file, or
    through broadcast location).



  • Client calls with arguments of name and required attribute, eg
    address. In DNS arguments are name and the type of requested
    attribute.



  • Server will return result with either required attribute or
    error message


2.9.12.1 Lookup Modes




If name not stored on server, may be stored on other server. Two options

Recursiveserver asks other possible server about name and
attribute, which may then have to ask another server and so on


\includegraphics{figs/recursive}



Iterativeserver returns address of other possible server to client, who then resends request to new server.


\includegraphics{figs/iterative}


2.9.13 Summary



  • Names can be flat, or they can be structured



  • Centralised name servers suffer from availability - distributed
    name servers suffer from inconsistency



  • Interaction with name server best modelled by RPC

2.10 Distributed File Systems


2.10.1 Main Points


A Distributed File System provides transparent access to files
stored on a remote disk


Themes:

  • Failures - what happens when server crashes but client doesn't?
    or vice versa
  • Performance
    $ \Rightarrow$ Caching - use caching at both the
    clients and the server to improve performance
  • Cache Coherence - how do we make sure each client sees most up
    to date copy of file?


2.10.2 Client Implementation



  • Request for operation on file goes to OS.
  • OS recognises file is remote and constructs RPC to remote file server
  • Server receives call, does operation and returns results.
  • Subtrees in directory structure generally map to file system.
    Provides access transparency


    \includegraphics{figs/remote-dir}


2.10.3 No Caching



  • Simple approach: Use RPC to forward each file system request to remote
    server (older versions of Novell Netware).
  • Example operations: open, seek, read, write, close
  • Server implements operations as it would for local request and passes
    result back to client


    Image simple-fs


2.10.3.1 Advantages and Disadvantages of uncached remote file
service


Advantageserver provides consistent view of file system to both A
and B.
Disadvantagecan be lousy performance

  • Going over network is slower than going through memory
  • Lots of network traffic - congestion
  • Server can be a bottleneck - what if lots of clients


2.10.4 NFS - Sun Network File System


Main idea - uses caching to reduce network load

  • Cache file blocks, file headers etc in both client and
    servers memory.
  • More recent NFS implementations use a disk cache at the client
    as well.



\includegraphics{figs/nfs-fs}

Advantage
Advantage: If open/read/write/close can be done locally, no network
traffic

Issues: failure and cache consistency


2.10.4.1 Failures


What if server crashes? Can client wait until server comes back up
and continue as before?

  1. Any data in server memory but not yet on disk can be lost
  2. If there is shared state across RPCs, eg open seek read. What
    if server crashes after seek? Then when client does ``read'' it will
    fail.
  3. Message re-tries - suppose server crashes after it does ``rm
    foo'' but before it sends acknowledgement? Message system will
    retry and send it again. How does system know not to delete it
    again (someone else may have created new ``foo''). Could use
    transactions, but NFS takes more ad hoc approach.

What if client crashes?

  1. Might lose modified data in client cache.


2.10.4.2 NFS Protocol



  1. Write-through caching - when a file is modified, all modified
    blocks are sent immediately to the server disk. To the client,
    ``write'' doesn't return until all bytes are stored on disk.
  2. Stateless Protocol - server keeps no state about client, except
    as hints to improve performance

    • Each read request gives enough information to do entire operation -
      ReadAt(inumber, position) not Read(openFile).
    • When server crashes and restarts, can start processing requests
      immediately, as if nothing had happened.


  3. Operations are idempotent: all requests are ok to repeat
    (all requests are done at least once). So if server crashes between
    disk I/O and message send, client can resend message and server
    does request over again

    • Read and write file blocks are easy - just re-read or re-write file
      block, so no side-effects.
    • What about ``remove''? NFS just ignores this - does the remove twice
      and returns error if file not found, application breaks if
      inadvertently removes other file.


  4. Failures are transparent to client system.


    Is this good idea? What should happen if server crashes? If
    application in middle of reading file when server crashes, options:

    1. Hang until server returns (next week...)
    2. return an error? But networked file service is transparent.
      Application doesn't know network is there. Many Unix Apps ignore
      errors and crash if there is a problem.

    NFS has both options - the administrator can select which one.
    Usually hang and return error if absolutely necessary.


2.10.4.3 Cache consistency



  • What if multiple clients sharing same files? Easy if they are both
    reading - each gets a local copy in their cache.
  • What if one writing? How do updates happen?
  • Note NFS has write-through cache policy. If one client modifies file,
    writes through to server.
  • How does other client find out about change?


2.10.4.4 NFS and weak consistency



  • In NFS, client polls server periodically to check if file has changed.
    Polls server if data hasn't been checked in every 3-30 seconds (Exact
    time is tunable parameter)


    \includegraphics{figs/nfs-cache}



  • When file changed on one client, server is notified, but other clients
    use old version of file till timeout. They then check server and get
    new version.
  • What if multiple clients write to same file? In NFS get either
    version or mixed version. Completely arbitrary!


2.10.4.5 Sequential ordering constraints



  • What should happen? If one CPU changes file, and before it completes,
    another CPU reads file?
  • We want isolation between operations, so read
    should get old file if it completes before write starts, new version if it
    starts after write completes. Either all new or all old any other
    way cf serialisability.


2.10.4.6 NFS Pros and Cons





  • its simple
  • its highly portable
  • but its sometimes inconsistent
  • but it doesn't scale to large numbers of clients



Note that this describes NFS version 3.


2.10.5 Andrew File System


AFS (CMU late 80s)
$ \Rightarrow$ DCE DFS (commercial product)

  1. Callbacks: Server records who has copies of file
  2. Write through on close

    • If file changes, server is updated (on close)
    • Server then immediately tells all those with old copy



2.10.5.1 AFS Session Semantics


Session semantics - updates only visible on close

  • In Unix (single machine), updates visible immediately to other
    programs who have file open.
  • In AFS, everyone who has file sees old version, anyone who opens file
    again will see new version.


    In AFS:

    1. on open and cache miss: get file from server, set up callback
    2. on write close: send copy to server; tells all clients with
      copies to fetch new version from server on next open

  • Files cached on local disk; NFS (used to) cache only in memory



\includegraphics{figs/AFS-cache}

  • What if server crashes? Lose all your callback state.
  • Reconstruct information from client - go ask everyone ``who has which
    files cached''


2.10.5.2 AFS Pros and Cons





  • Disk as cache
    $ \Rightarrow$ more files cached locally
  • Callbacks
    $ \Rightarrow$ server not involved if file is
    read-only (Majority of file access is read-only)
  • But on fast LANs, local disk is slower than remote memory



NFS version 4 will provide session semantics when it is
deployed by vendors in the 2005 timeframe.


2.10.6 Summary





  • Remote file performance needs caching to get decent performance.



  • Central server is a bottleneck

    • Performance bottleneck:

      • All data is written through to server
      • all cache misses go to server


    • Availability Bottleneck

      • Server is single point of failure


    • Cost bottleneck

      • Server machines high cost relative to workstation



2.12 Content Distribution Networks


Main Points

  • Building content caches
  • Pre-fetching data
  • Using your neighbours - BitTorrent

2.12.1 Getting Content over a Network




Image cdn-base



  • Users want to download content from serversas quickly as possible
  • What structures can we use to improve their experience, and the
    impact upon the network?

2.12.2 Web Caches


Image cdn-cache

  • Large organisations can improve web performance by sticking a
    web cache in front of HTTP connections
  • The cache inspects an incoming HTTP request to see if it can
    satisfy the request from locally cached objects.
  • If yes, then the object is returned, and the last reference time
    is updated
  • If no, then the object is retrieved and copied locally if allowed.
  • Web objects can be marked as non-cacheable.
  • Caching is a major part of the HTTP standard

2.12.2.1 Cache Performance




  • The performance of a web cache is difficult to model, since the
    performance is a complex mixture of interaction between TCP, HTTP
    and content.
  • Caches work because of temporal locality, due to popularity of
    content, and spatial locality, due to structure of HTML documents
  • Measurements of web proxies give the following results (based on
    JANET caches)

    • Request hit rate is about 60%.
    • Volume hit rate is about 30%.
    • Latency improvement is around a factor of 3 on average



2.12.2.2 Problems with Caching



  • Not all content is marked as cacheable, eg because the site
    wants accurate records of who looks at content.
  • All hosts behind a cache appear to come from one
    address.

    Question: Why is this a problem?

2.12.3 Pre-fetching Data



  • Can we improve performance by pro-actively distributing content
    to caches?
  • Yes...

2.12.3.1 Active Content Distribution



  • The html uses links to the cdn domain name eg akamai.com
  • The internet service provider has entries in their local DNS for
    akamai.com pointing to a machine on the ISP's network.
  • Content will therefore be supplied from the local machine rather
    than the original machine
  • Customer interaction improved.
  • Bandwidth requirements of servers reduced

2.12.4 Using your Peers: BitTorrent


Image cdn-torrent

  • Why not use the other people receiving the content?
  • BitTorrent downloads from other machines
  • Basic Idea:

    • To download, the host contacts a machine tracking those already
      downloading the torrent.
    • Peers are selected at random from the tracker.
    • Pieces are selected to download from those available on the
      downloader's peer set until all pieces of the file have been received

2.12.4.1 The .torrent file



  • To start downloading from a torrent, the consumer must
    first locate a .torrent file.
  • This contains information about the file length, name and
    hashing numbers of the file blocks, and the url of a tracker
  • The file is split into 250 KByte pieces, each having a SHA1 hash
    calculated.
  • A tracker holds the IP addresses of current downloaders

2.12.4.2 Locating peers



  • After receiving the torrent file, the downloader contacts the
    tracker
  • The tracker inserts the downloader into its list of downloaders,
    and returns a random list of other downloaders
  • This list becomes the downloader's peers
  • Question What is the shape of the overlay Graph?

2.12.4.3 Choosing Pieces



  • The downloader will contact its peers to discover what pieces
    they have.
  • It then chooses a piece to download:
  • The first choice is made randomly, so as to spread load
  • Subsequent pieces are based on a rarest-first approach to
    increase probability all pieces are available.
  • When a peer has downloaded a new piece which matches the SHA1
    hash, it notifies its peers it has a new piece.

2.12.4.4 Choosing Downloaders



  • A request to upload is accepted if the requester recently
    uploaded to it
  • This provides an incentive to machines to share data
  • Periodically other machines are tried for upload

2.12.5 Summary



  • Web caching improves performance by a reasonable factor,
    dependent on situation
  • Pro-active content distribution can reduce latency and improve
    bandwidth usage for popular services
  • BitTorrent can improve bandwidth usage by spreading load across
    peers.

2.13 Replication: Availability and Consistency



  • Motivation for replication
  • Multicasting updates to a group of replicas
  • Total Ordering
  • Causal Ordering
  • Techniques for ordering protocols
  • ISIS CBCAST


2.13.1 What is Replication?




  • Multiple copies of dynamic state stored on multiple machines
    eg Copies of files stored on different machines, name servers storing
    name address mappings

  • Caching can be seen as a form of replication.


2.13.1.1 Why is Replication used?


Performance enhancement



  • Single Server acts as a bottleneck - if we can balance load
    amongst multiple servers, get apparent performance gain
  • If clients are geographically distributed, we can site servers
    near clients and reduce communication costs


Availability



  • If a machine fails, then we can still provide a service
  • Probability of total failure reduced such as all data being
    lost, since data replicated across multiple machines
  • If probability of failure is pr(fail ) for a given machine
    in n machines, then probability of loss of service is
    pr(fail )n and the availability of the service is
    1 - pr(fail )n
  • eg, if mean time between failure for 3 machines is 5 days,
    repair time is four hours, then assuming independence of failure,

    pr(fail )= $ {\frac{{4}}{{5 \times 24}}}$ = 0.03.


    Availability =
    1 - 0.033 = 99.996%





Fault ToleranceEven in the presence of failure, the service
will continue to give the correct service

  • Stronger than availability, since can provide real-time
    guarantees (with extra work!)
  • Can protect against arbitrary failure where machines feed
    wrong information (Byzantine Failure)


2.13.2 Issues in Replication


A collection of replicas should behave as if state was stored
at one single site

  • When accessed by client, view should be consistent
  • Replication should be transparent - client unaware that servers
    are replicated



If we are providing a replica service, replica can be passive or
active.



Passive replicas are standbys, to maintain service on failure. No
performance improvement.


Standbys must monitor and copy state of active server


Provide availability in simple manner.


Used for highly available systems eg space applications


2.13.3 Consistency





  • Clients can modify resource on any of the replicas.
  • What happens if another client requests resource before replica
    has informed others of modification, as in cache consistency in
    distributed file systems?
  • Answer depends upon application...


2.13.3.1 Example Distributed Bulletin Board System (BBS)


\includegraphics{figs/bbs}

  • Users read and submit articles through Front End.
  • Articles replicated across a number of servers
  • Front Ends can connect to any server
  • Servers propagate articles between themselves so that all
    servers hold copies of all articles.
  • User membership of a given bbs is tightly controlled.



Questions on BBS:

  • How should messages be passed between replicas?
  • Should order of presentation of articles to clients be the same
    across all replicas? Are weaker ordering semantics possible?
  • When a client leaves bbs group, can they see articles submitted
    after they have left? Is this desireable?
  • What should happen when replicas are temporarily partitioned?


2.13.4 Updating Server state




Clients read and update state at any of the replicated servers eg
submit messages in bbs. To
maintain consistency, three things are important

Multicast communicationMessages delivered to all servers in
the group replicating data
Ordering of messagesUpdates occur in the same ``order'' at
each server
Failure recoveryWhen servers or the network fails, and comes
back, the replicas must be able to regain consistency. Done through
Voting and Transactions (later in course)


2.13.5 Multicast and Process Groups




A Process Group: a collection of processes that co-operate
towards a common goal.


Multicast communication: One message is sent to the members of a
process group


Idea: Instead of knowing address of process, just need to know an
address representing the service. Lower levels take care of routing
messages.


Useful for:

Replicated ServicesOne update message goes to all replicas,
which perform identical operations. Reduces communication costs.
Locating objects in distributed servicesRequest for object
goes to all processes implementing service, but only process holding
object replies.


2.13.5.1 Group Services




Maintenance of group information is a complex function of the name
service (for tightly managed groups)

Create GroupCreate a group identifier that is globally
unique.
Join GroupJoin a group. Requires joining process information
to be disseminated to message routing function. May require
authentication and notification of existing members.
Leave GroupRemove a process from a group. May require
authentication, may occur as a result of failure or partition. Need
to notify message routing function, may notify other members.
Member ListSupply the list of processes within a group.
Needed for reliable message delivery, may require authentication.


2.13.6 Message Ordering




If two processes multicast to a group, the messages may be arbitrarily
ordered at any member of the group.


Process P1 multicasts message a to a group comprising processes P1, P2, P3 and
P4.


Process P2 multicasts message b to the same group


The order of arrival of a and b at members of the group can be different.


\includegraphics{figs/order}


2.13.6.1 Ordering example




\includegraphics{figs/causal-object}

  • Order of operations may be important - delete object, create
    object.
  • If delete object arrives before create object, then operation
    not completed


2.13.6.2 Ordering Definitions




Various definitions of order with increasing complexity in
multicasting protocol

FIFO OrderingMessages from one process are processed at all
group members in same order
Causal OrderingAll events which preceded the message
transmission at a process precede message reception at other
processes. Events are message receptions and transmissions.
Total OrderingMessages are processed at each group member in
the same order.
Sync OrderingFor a sync ordered message, either an event
occured before message reception at all processes, or after
message. Other events may be causally or totally ordered.


2.13.6.3 FIFO ordering




Achieved by process adding a sequence number to each message.


Group member orders incoming messages with respect to sequence number.


Applicable when each process state is separate, or operations don't
modify state, just add incremental updates or read.


2.13.6.4 Total Ordering




When several messages are sent to a group, all members of the group
receive the messages in the same order.


Two techniques for implementation:

Sequencer
      Elect a special sequencing node. All messages are
sent to sequencer, who then sends messages onto replicas. FIFO
ordering from sequencer guarantees total ordering. Suffers from
single point of failure (recoverable by election) and bottleneck.

Holdback Queue
       Received messages are not passed to the
application immediately, but are held in a holdback queue
until the ordering constraints are met.


2.13.6.4.1 Sequence Number Negotiation

Sender negotiates a largest
sequence number with all replicas.

  1. Replicas store largest final sequence number yet seen Fmax,
    and largest proposed sequence number Pmax
  2. Sender sends all replicas message with temporary ID.
  3. Each Replica i replies with suggested sequence number of
    max(Fmax, Pmax) + 1. Suggested sequence number
    provisionally assigned to message and message placed in holdback
    queue (ordered with smallest sequence number at front)
  4. Sending site chooses largest sequence number and notifies
    replicas of final sequence number. Replicas replace provisional
    sequence number with final sequence number.
  5. When item at front of queue has an agreed final sequence number,
    deliver the message.



2.13.6.5 Causal Ordering




``Cause'' means ``since we don't know application, messages might have
causal ordering''


a and b are events, generally sending and receiving of
messages.


We define the causal relation,
a $ \rightarrow$ b, if

  1. if a and b are events at the same process,

    a $ \rightarrow$ b implies a happened before b
  2. if a is a message sent by process P1 and b is
    the arrival of the same message at P2, then
    a $ \rightarrow$ b is true



In bulletin board, an article titled ``re: Multicast Routing'' in
repsonse to an article called ``Multicast Routing'' should always come
after, even though may be received before the initial article


2.13.6.6 CBCAST - Causal ordering in ISIS


ISIS is a real commercial distributed system, based on process groups.


Causal ordering for multicast within a group is based around
Vector Timestamps


The vector VT has an identifier entry for each member of the
group, typically an integer.


Vector timestamps have one operation defined



merge(u, v)[k] = max(u[k], v[k]), for k = 1..n


Incoming messages are placed on a holdback queue, until all messages
which causally precede the message have been delivered.



2.13.6.6.1 CBCAST Implementation





  1. All processes pi initialise the vector to zero
  2. When pi multicasts a new message, it first increments VTi[i] by 1; it piggybacks
    vt = VTi on the message



  3. Messages are delivered to the application in process Pj when

    • The message is the next in sequence from pi i.e.
      vt[i] = VTj[i] + 1
    • All causally prior messages that have been delivered to pi must have been delivered to pj, i.e.
      VTj[k] $ \geq$ vt[k] for k $ \neq$ i.


  4. When a message bearing a timestamp vt is delivered to pj, pj's timestamp is updated as
    VTj = merge(vt, VTj)



In words

  • Incoming vector timestamp is compared to current timestamp.
  • If conditions for delivery to process not met, then message placed on
    holdback queue.
  • When an incoming message is delivered, the timestamp is updated by the
    merge.
  • Examine all messages in the holdback queue to see if they can be
    delivered.
  • CBCAST requires reliable delivery.


2.13.6.6.2 Causal Example


\includegraphics{figs/causal}


2.13.6.6.3 Group View Changes



  • When group membership changes, what set of messages should be
    delivered to members of changed group?
  • What happens to undelivered messages of failed members?
  • What messages should new member get?
  • ISIS solves by sending a sync ordered message announcing
    that the group view has changed. Messages thus belong to a
    particular group view.
  • Use coordinator to decide which messages belong to which view.


2.13.7 Summary



  • Replication of services and state increase availability
  • Replication increases performance
  • Replication increases Fault tolerance
  • To maintain consistency, multicast updates to all replicas
  • Use sequence numbers to maintain FIFO ordering
  • Use Vector Timestamps to maintain Causal Ordering
  • Use elected sequencers or identifier negotiation to maintain
    total ordering



2.14 Shared Data and Transactions





  • Stateful Servers
  • Atomicity
  • Transactions
  • ACID
  • Serial Equivalence


2.14.1 Servers and their state





  • Servers manage a resource, such as a database or a printer
  • Attempt to limit problems of distributed access by making server
    stateless, such that each request is independent of other
    requests.

    • Servers can crash in between servicing clients
    • Client requests cannot interfere with each other (assuming
      concurrency control in server


  • But we can't always design stateless servers...


2.14.1.1 Stateful Servers



  • Some applications better modelled as extended
    conversations, eg retrieving a list of records in a
    large database better modelled as getting batch of records at a
    time.
  • If application requires state to be consistent across a number
    of machines, then each machine must recognise when it can update
    internal data. Needs to keep track of state of distributed
    conversation
  • If long duration then, then need to be aware of state.
  • If other conversations need to go on - eg modify records during
    retrieval, how do we allow concurrency?
  • What happens if machine fails - need to recover.
  • Should also aim to be fault tolerant


2.14.2 Atomicity


Stateful server have two requirements

  1. Accesses from different clients shouldn't interfere
    with each other
  2. Clients should get fast access to the server


2.14.2.1 Definition


We define atomicity as
All or NothingA client's operation on a server's resource
should complete successfully, and the results hold thereafter (yea,
even unto a server crash), or it should fail and the resource should
show no effect of the failed operation
IsolationEach operation should proceed without interference
from other clients' operations - intermediate effects should not be
visible.


2.14.2.2 Example


Mutual ExclusionFor a multi-threaded server, if two or more
threads attempt to modify the same piece of data, then the updates
should have mutual exclusion around the updates to provide
isolation, using semaphores or monitors
SynchronisationIn situations such as Producer Consumer, need
to allow one operation to finish so second operation can use
results, needing isolation.


2.14.3 Automatic Teller Machines and Bank accounts




\includegraphics{figs/cashmachine}



  • An ATM or cashmachine allows transfer of funds between accounts.
  • Accounts are held at various machines belonging to different
    banks
  • Accounts offer the following operations
    depositPlace an amount of money in an account

    withdrawTake an amount of money from an account

    balanceGet the current value in an account


  • Operations implemented as read() and write() of values, so
    withdraw x from A and deposit x in B implemented as

    1. A.write( A.read()  - x)
    2. B.write( B.read() + x)




2.14.4 Transactions


Transactions are technique for grouping operations on data so that
either all complete or none complete


Typically server offers transaction service, such as:

beginTransaction(transId)Record the start of a transaction and
associate operations with this transId with this transaction.
commitTransaction(transId)Commit all the changes the
operations in this transaction have made to permanent storage.
abortTransaction(transId)Abort all the changes the transaction
operations have done, and roll back to previous state.



2.14.4.1 ACID




Transactions are described by the ACID mnemonic

AtomicityEither all or none of the Transaction's operations
are performed. If a transaction is interrupted by failure, then
partial changes are undone
ConsistencySystem moves from one self-consistent state to another
IsolationAn incomplete transaction never reveals partial state
or changes before commiting
DurabilityAfter committing, the system never loses the results
of the transaction, independent of any subsequent failure

2.14.4.2 Concurrency Problems

2.14.4.2.1 Lost Update






























































Transaction T Transaction U 
A.withdraw(4,T) C.withdraw(3,U) 
B.deposit(4,T) B.deposit(3,U) 
balance = A.read()£100  
A.write(balance - 4)£96  
  balance = C.read()£300
  C.write(balance - 3)£297
balance = B.read()£200  
  balance = B.read()£200
  B.write(balance + 3)£203
B.write(balance + 4)£204  




2.14.4.2.2 Inconsistent Retrievals


































































Transaction T Transaction U 
A.withdraw(100,T) Bank.total(U) 
B.deposit(100,T)   
balance = A.read()£200  
A.write(balance - 100)£100  
  balance = A.read()£100
  balance = B.read()£300
  + balance 
  balance = C.read()£300+
  + balance 
balance = B.read()£200  
B.write(balance + 100)£300  




2.14.5 Serial Equivalence


Definition: Two transactions are serial if all the operations in
one transaction precede the operations in the other.


eg the following actions are serial



Ri(x)Wi(x)Ri(y)Rj(x)Wj(y)


Definition: Two operations are in conflict if:

  • At least one is a write
  • They both act on the same data
  • They are issued by different transactions




Ri(x)Rj(x)Wi(x)Wj(y)Ri(y) has
Rj(x)Wi(x) in conflict


Definition: Two schedules are computationally equivalent if:

  • The same operations are involved (possibly reordered)
  • For every pair of operations in conflict, the same operation
    appears first in each schedule

So, a schedule is serialisable if the schedule is computationally
equivalent to a serial schedule.


Question: Is the following schedule for these two transaction serially
equivalent?



Ri(x)Ri(y)Rj(y)Wj(y)Ri(x)Wj(x)Wi(y)



2.14.5.1 Transaction Nesting




Transactions may themselves be composed of multiple transactions


eg Transfer is a composition of withdraw and
deposit transactions, which are themselves composed of read and
write transactions


Benefits:

  • Nested transactions can run concurrently with other transactions
    at same level in hierarchy
  • If lower levels abort, may not need to abort whole transaction.
    Can instead use other means of recovery.


2.14.6 Summary





  • Transactions provide technique for managing stateful servers
  • Need to worry about concurrency control
  • Need to worry about aspects of distribution
  • Need to worry about recovery from failure


2.15 Concurrency Control and Transactions





  • Problem restatement
  • Locking
  • Optimistic control
  • Timestamping


2.15.1 Why concurrency control?





  • To increase performance, multiple transactions must be able to
    carry on work simultaneously...
  • ...but if data is shared, then can lead to problems such as lost
    updates and inconsistent retrievals.
  • So we must ensure schedules of access to data for concurrent
    transactions are computationally equivalent to a serial schedule of
    the transactions.


2.15.2 Locking





  • As in operating systems, locks control access for different
    clients
  • Granularity of data locked should be small so as to maximise
    concurrency, with trade-off against complexity.
  • To prevent intermediate leakage, once lock is obtained, it must
    be held till transaction commits or aborts


2.15.2.1 Conflict rules





  • Conflict rules determine rules of lock usage
  • If operations are not in conflict, then locks can be shared
    $ \Rightarrow$ read locks are shared
  • Operations in conflict imply operations should wait on lock
    $ \Rightarrow$ write waits on read or write lock, read waits on write
    lock
  • Since can't predict other item usage till end of transactions,
    locks must be held till transaction commits or aborts.
  • If operation needs to do another operation on same data then
    promotes lock if necessary and possible - operation may
    conflict with existing shared lock


2.15.2.2 Rules for strict two phase locking





  1. When operation accesses data item within transaction

    1. If item isn't locked, then server locks and proceeds
    2. If item is held in a conflicting lock by another transaction,
      transaction must wait till lock released
    3. If item is held by non-conflicting lock, lock is shared and
      operation proceeds
    4. If item is already locked by same transaction, lock is
      promoted if possible (refer to rule b)


  2. When transaction commits or aborts, locks are released


2.15.2.3 Locking Implementation





  • Locks generally implemented by a lock manager
    lock(transId,DataItem,LockType)Lock the specified item if
    possible, else wait according to rules above

    unLock(transId)Release all locks held by the transaction


  • Lock manager generally multi-threaded, requiring internal
    synchronisation
  • Heavyweight implementation


2.15.2.4 Example


Transactions T and U.

  • T:
    RT(i), WT(j, 44)
  • U:
    WU(i, 55)), RU(j), WU(j, 66)

Question What are the possible schedules allowed under strict
locking?


Question Are there any schedules computationally equivalent
to a serial schedule which are disallowed?



2.15.2.5 Deadlocks





  • Locks imply deadlock, under following conditions

    1. Limited access (eg mutex or finite buffer)
    2. No preemption (if someone has resource can't take it away)
    3. Hold and wait. Independent threads must possess some of its needed resources and waiting for the remainder to become free.
    4. Circular chain of requests and ownership.

  • Most common way of protecting against deadlock is through
    timeouts. After timeout, lock becomes vulnerable and can be
    broken if another transaction attempts to gain lock, leading to
    aborted transactions


2.15.2.6 Drawbacks of Locking





  • Locking is overly restrictive on the degree of concurrency
  • Deadlocks produce unnecessary aborts
  • Lock maintenance is an overhead, that may not be required


2.15.3 Optimistic Concurrency Control



  • Most transactions do not conflict with each other
  • So proceed without locks, and check on close of transaction that
    there were no conflicts

    • Analyse conflicts in validation process
    • If conflicts could result in non-serialisable schedule, abort
      one or more transactions
    • else commit




2.15.3.1 Implementation of Optimistic Concurrency Control


Transaction has following phases

  1. Read phase in which clients read values and acquire tentative
    versions of items they wish to update
  2. Validation phase in which operations are checked to see if they
    are in conflict with other transactions - complex part. If invalid,
    then abort.
  3. If validated, tentative versions are written to permanence, and
    transaction can commit (or abort).


2.15.3.2 Validation approaches





  • Validation based upon conflict rules for serialisability
  • Validation can be either against completed transactions or
    active transactions - backward and forward validation.
  • Simplify by ensuring only one transaction in validation and
    write phase at one time
  • Trade-off between number of comparisons, and transactions that
    must be stored.


2.15.3.2.1 Forward Validation



  1. A transaction in validation is compared against all
    transactions that haven't yet committed
  2. Writes may affect ongoing reads
  3. The write set of the validating transaction is compared
    against the read sets of all other active transactions.
  4. If the sets conflict, then either abort validating
    transaction, delay validation till conflicting transaction
    completes, or abort conflicting transaction.


2.15.3.2.2 Backward validation



  1. Writes of current transaction can't affect previous
    transaction reads, so we only worry about reads with overlapping
    transactions that have committed.
  2. If current read sets conflict with already validated
    overlapping transactions write sets, then abort validating
    transaction

2.15.4 Timestamping


Operates on tentative versions of data

  • Each Transaction receives global unique timestamp on initiation
  • Every object, x, in the system or database carries the maximum (ie
    youngest) timestamp of last transaction to read RTM(x)2.3 and maximum of last transaction to write
    WTM(x)2.4
  • If transaction requests operation that conflicts with younger
    transaction, older transaction restarted with new timestamp.
  • Transactions committed in order of timestamps, so a transaction
    may have to wait for earlier transaction to commit or abort before
    committing.
  • Since tentative version is only written when transaction is
    committed, read operations may have to wait until the last
    transaction to write has committed.



An operation in transaction Ti with start time TSi
is valid if:

  • The operation is a read operation and the object was last
    written by an older transaction ie
    TSi > WTM(x). If read permissible,
    RTM(x) = MAX(TSi, RTM(x))
  • The operation is a write operation and the object was
    last read and written by older transactions ie

    TSi > RTM(x) and
    TSi > WTM(x). If permissible,
    WTM(x) = TSi


2.15.5 Summary



  • Locks are commonest ways of providing consistent concurrency
  • Optimistic concurrency control and timestamping used in some
    systems
  • But, consistency in concurrency is application dependent - for
    shared editors, people may prefer to trade speed of execution
    against possibilities of conflict resolution. Problems can occur
    with long term network partition. Approaches based on notification
    and people resolution becoming popular.



2.16 Distributed Transactions





  • Models for distributed transactions
  • Attaining distributed commitment
  • Distributed Concurrency Control


2.16.1 Single Server Transactions




\includegraphics{figs/single-server-trans}



  • Till now, transactions have referred to multiple clients, single
    server.
  • How do we have multiple clients interacting with multiple
    servers? eg complicated funds transfer involving different accounts
    from different banks?
  • Generalise transactions to distributed case...

2.16.2 Distributed Transactions


2.16.2.1 Distributed Transaction Requirements


General characteristics of distributed systems

  • Independent Failure Modes
  • No global time
  • Inconsistent State



Need to consider:

  • how to achieve distributed commitment (or abort)
  • how to achieve distributed concurrency control


2.16.2.2 Models


\includegraphics{figs/transaction-models}



  • If client runs transactions, then each transaction must complete
    before proceeding to next
  • If transactions are nested, then transactions at same level can
    run in parallel
  • Client uses a single server to act as coordinator for all
    other transactions. The coordinator handles all communication with
    other servers



Question: What are the requirements of transaction ids?


2.16.3 Atomic Commit Protocols





  • Distribution implies independent failure modes, ie machine can
    fail at any time, and others may not discover.
  • If one phase commit, client requests commit, but one of
    the server may have failed - no way of ensuring durability
  • Instead, commit in 2 phases, thus allowing server to request abort.


2.16.3.1 2 Phase Commit



  • One coordinator responsible for initiating protocol.



  • Other entities in protocol called participants.
  • If coordinator or participant unable to commit, all parts of
    transaction are aborted.



  • Two phases
    Phase 1Reach a common decision

    Phase 2Implement that decision at all sites


2.16.3.1.1 2 Phase Commit Details





  1. Phase 1 The coordinator sends a Can Commit? message to all
    participants in transaction.
  2. Participants reply with vote yes or no. If vote
    is no participant aborts immediately.
  3. Phase 2 Coordinator collects votes including own:

    1. If all votes are yes, coordinator commits transaction
      and sends DoCommit to all participants.
    2. Otherwise transaction is aborted, and coordinator sends abortTransaction to all participants.


  4. When a participant recieves DoCommit, it commits its
    part of the transaction and confirms using HaveCommited

2.16.3.1.2 2 Phase Commit Diagram




\includegraphics{figs/2phasecommit}


Note:

  • If participant crashes after having voted to commit, it can ask
    coordinator about results of vote.
  • Timeouts are used when messages are expected.
  • Introduces new state in transaction Prepared to commit.

2.16.4 Distributed Concurrency Control


2.16.4.1 Locking



  • Locking is done per item, not per client.
  • No problems generalising to multiple servers...
  • ...except in dealing with distributed deadlock
  • Same techniques as usual, but interesting dealing with
    distributed deadlock detection.


2.16.4.2 Optimistic Concurrency Control



  • Need to worry about distributed validation
  • Simple model of validation had only one transaction being
    validated at a time - can lead to deadlock if different cordinating servers
    attempt to validate different transaction.
  • Also need to validate in correct serialisable order.
  • One solution is to globaly only allow one transaction to
    validate at a time.
  • Other solutions is to validate in two phases with timestamp
    allocation - local, then global to enforce ordering.


2.16.4.3 Timestamping



  • If clocks are approximately synchronised, then timestamps can be


    < localtimestamp, coordinatingserverid >


    pairs, and an ordering
    defined upon server ids.


2.16.5 Summary





  • Nested Transactions are best model for distributed transactions
  • Two Phase Commit protocol suitable for almost all case
  • Distributed Concurrency control is only slightly more diffcult
    than for single server case

2.17 Transactions: Coping with Failure



  • Failure Modes
  • Recovery Techniques
  • Partitions and quorum voting


2.17.1 Failure Modes


For Transactions to be atomic and durable, need to examine
failures

  1. Transaction-local failures, detected by the application which
    calls abort eg insufficient funds. No info loss, need
    to undo changes made.
  2. Transaction-local failures , not detected by application, but by
    system as whole, eg divide by zero. System calls abort.
  3. System failures affecting transactions in progress but not media
    eg CPU failure. Loss of volatile store and possibly all
    transactions in progress. On recovery, special recovery manager
    undoes effects of all transactions in progress at failure.
  4. Media failures affecting database eg head crash. No way of
    protecting against this.





2.17.2 Recovery



  • We assume a machine crashes, but then is fixed and returns to operation2.5.
  • We need to recover state to ensure that the guarantees of the
    transactional systems are kept.
  • Use a recovery file or log that is kept on permanent storage.


2.17.2.1 The Recovery Manager





  • Recovery from failure handled by entity called Recovery Manager.
  • Keeps information about changes to the resource in a recovery file (also called Log)
    kept in stable storage - ie something that will survive failure.
  • When coming back up after failure, recovery manager looks through
    recovery file and undoes changes (or redoes changes) so as uncommitted
    transactions didn't happen, and committed transactions happened.
  • Events recorded on Recovery file for each change to
    an object in database.


2.17.2.2 Recovery File


Information recorded per event include:
Transaction IdTo associate change with a transaction
Record IdThe identifier of the object
Action typeCreate/Delete/Update etc
Old ValueTo enable changes to be undone
New ValueTo enable changes to be redone

Also log beginTransaction, prepareToCommit, commit, and abort actions,
with their associated transaction id.


2.17.2.3 Recovering


If after failure,

  • the database is undamaged, undo all changes made by
    transactions executing at time of failure
  • the database is damaged, then restore database from archive and
    redo all changes from committed transactions since archive date.

The Recovery file entry is made and committed to stable storage before
the change is made - incomplete transactions can be undone, committed
transactions redone.


What might happen if database changed before recovery file written?


Note that recovery files have information needed to undo transactions.



2.17.2.4 Checkpointing




Calculation of which transaction to undo and redo on large logs can be
slow.


Recovery files can get too large


Instead, augment recovery file with checkpoint

  • Force recovery file to stable storage
  • Write checkpoint record to stable store with

    1. A list of currently active transactions
    2. for each transaction a pointer to the first record in
      recovery file for that transaction


  • Force database to disk
  • Write address of checkpoint record to restart location atomically


2.17.2.5 Recovering with checkpoints




To recover, have undo and redo lists. Add all active transactions at
last checkpoint to undo list

  1. Forwards from checkpoint to end,

    1. If find beginTransaction add to undo list
    2. If find commit record add to redo list
    3. If find abort record remove from undo list


  2. backwards from end to first record in checkpointed transactions,
    execute undo for all transaction operations on undo list
  3. Forwards from checkpont to end, redo operations for transactions
    on redo list



At checkpoint can discard all recovery file to first logged record in
checkpointed transactions



2.17.2.6 Recovery of the Two Phase Commit Protocol




\includegraphics{figs/2phasecommit}

  • Coordinator uses prepared to signal starting protocol,
    commit on signalling DoCommit and done to indicate end
    of protocol in recovery file.
  • Participant uses uncertain to indicate that it has
    replied yes to commit request, and commited when it
    receives DoCommit.
  • On recovery, coordinator aborts transactions which reach
    prepared, and resends DoCommit when in commit state
    but not done
  • Participant requests decision from coordinator if in
    uncertain state, but not commited.


2.17.3 Network Partition


Transactions are often used to keep replicas consistent.


If network partitions (cable breaks), replicas divided into two or more sets
(possibly with common members).


\includegraphics{figs/partition}


Can we still write and read from any of the sets?


Yes, but

  • Must reduce possible read and write sets to maintain consistency
  • Or relax consistency requirements and resolve problems when
    partition is healed


2.17.3.1 Quorum Consensus


Consider set of replicas, where replicated objects have version
numbers at each replica.

  1. Assign a weighting of votes to each replica, indicating importance.
  2. For client to perform operation, it must gather votes for all the
    replicas it can talk to (denote X).
  3. X$ \ge$ votes set for read quorum R to enable read
  4. X$ \ge$ votes set for write quorum W to enable write.
  5. As long as

    • W > half the total number of votes
    • R + W > total number of votes in group

    Each Read quorum and each write quorum will have at least one member
    in common.


2.17.3.2 Partition Example


For three replicas, R1, R2, R3, we can allocate votes to give
different properties depending upon requirements





















Replicaconfig 1config 2config 3
R1121
R2011
R3011


  1. What should R and W be set to in the three
    configurations?
  2. What properties result from these configurations?


2.17.3.3 Read and Write Operations




When write happens, object has a version number incremented


To read, collect votes from replica managers with version numbers of
object. Guaranteed to have at least one up to date copy if in read
quorum, from which read occurs.


To write, collect votes from replica managers with version numbers of
object. If write quorum with up to date copy not discovered, then
copy up to date copy around to create write quorum. Then write is
allowed.


Manipulating R and W give different characteristics eg R = 1 and W = number of copies gives unaminous update.


Cached copies of objects can be incorporated as weak
representatives with 0 votes, but usable for reads.



2.17.4 Summary



  • Atomicity comes from using logging techniques on operations at
    server, where log is kept on stable storage
  • Voting can be used to give availability for resources on
    partitioned replicas.


3. Exercises and answers



发帖者 时间： 没有评论:

2009年3月26日星期四

"福施福"批准文号已经失效6年依然大量销售

    09年04月10日上午，某个自称是药监局的中年妇女给我打电话，来电显示号码：010-88372260，询问怎么买的。我说生产商都告诉你了，为什么不去调查。她讥笑我不懂人家的职能。说你既然举证人家，将来是要上法庭的。问我在那个正规药店购买的。我说淘宝上大量销售，她以一副领导者的口吻，说他们药监局没有建议广大人民群众去网上购买药品，应该去正规药店，有病去看医生，而且网上的事归信产部管。我说是保健品，她说“卫进食”，这是食品，食品阿，归质检局管。
然后，又质询我，在哪儿买的。
询问我专业，大声感叹，“隔行如隔山阿”，讥笑不动专业知识，没有办法交谈。怎么知道人家福施福没有重新注册，没有更换名字重新注册？我说我查了阿，199种你们批准的进口保健食品里没有啊。大嫂继续教导：人家是“食”字啊，是食品，不归药监局管。
最后，说我既然对买的有疑问，在哪儿买的去哪儿投诉。

个人看法：
 1， 你国家食品药品监督管理局既然挂“食品药品监督管理”的牌子，我一个老百姓当然到你这儿投诉了。你讥笑我不懂你的职能，只能说明你工作不到位，你咋不在你网站首页写明四个大字“不管食品”阿。
 2， 到底什么归你管，什么不归你管。按照这位大嫂的想法，最好啥都不要管。
 3， 如果说“食”字不归你管，那你批准的199种进口保健食品里,卫进食健字(1998)第027号为什么在你批准的进口保健食品列表中，你到底管不管？
 4， 根据"福施福"的化学成分，毫无疑问是药品而不是食品，在英国也是做为药品批准的。而在中国，由于管理的混乱，把药品按照保健品批准，已经是错的，主动放弃自己的监管责任，更是无可救药！


"福施福"批准文号已经失效6年依然大量销售



目前在中国市场上和taobao等网店大量销售的“福施福”营养素软胶囊的批准文号早已过期，应当停止销售。

[英文名] Forceval

[中文名] 福施福营养素补充剂软胶囊

[制造商] 英国优尔格药业有限公司

[进口商] 广州福胜医药生物科技有限公司

[批准文号]卫进食健字[1998]第009号

网址: http://www.fushifu.cn/

卫食健字是国家卫生部2003年前期的批准号，自2004年国家成立了食品药品管理监督局后，卫食健字号一律要重新审批转为国食品健字号。根据2005年由国家食品药品监督管理局颁布的《保健食品注册管理办法（试行）》中的第二章第二节第三十三条 规定，保健食品批准证书有效期为5 年。该公司没有得到药监局的重新审批，早已不允许销售。广州福胜医药生物科技有限公司在批准文号早已过期的情况下，仍然在市场上使用该批准文号大量销售该产品。





假冒产品是指使用不真实的厂名、厂址、商标、产品名称、产品标识等从而使客户、消费者误以为该产品就是被假冒的产品。

伪劣产品是指质量低劣或者失去使用性能的产品。





【市场报】“福施福”营养素保健品3疑

《市场报》 (2004年08月24日 第六版)

本报记者  王继红



最近，一种英国生产的“福施福”营养素补充剂软胶囊保健品，被宣传为国家计生委“出生缺陷干预工程”选用产品，说是国家为了预防胎儿神经血管畸形，加强优生优育，推行的孕妇保健药品。一些地方的计生委在办理准生证时，要求办证者必须购买一个疗程共6盒“福施福”，个别经济贫困、生活条件不好的地区至少买 3盒，每盒价格为55元。更恶劣的是，一个办准生证的妇女拿到的“福施福”保健食品，竟然已经过期2个月，而且购买此产品还不给开发票。这种硬性搭售、强行卖给的行为，引起准母亲们的不满。广州、河南、四川、重庆、青海等地的众多媒体以“办理准生证要买保胎药”，“办准生证必须搭售保健品”为题揭露了此事。



本报也接连接到群众来信、来电，有的投诉者还寄来产品，除了反映此种强卖行为，还说到该保健品本身的一些违法违规的问题。



一位河北姓杜的消费者来信说，他认为“福施福”有3点违反了国家有关法律法规：一是商标标识有问题。卫生部进口保健品批准证书上标明，该保健食品名称是：福施福（营养素补充剂），而该产品上却写着福施福孕妇营养素补充剂软胶囊，“孕妇”这个表示特定人群的字眼是经销商自己加上的。二是原料进口不是原装进口。该产品在外包装上写着英国生产，给人以原装进口保健品的感觉。但我国海关入境检验检疫卫生证书上写着进口的是原料，显然产品是在国内包装上市的，但在产品上没有国内加工企业名称和生产许可证标识。三是外包装公然写着国家计生委“出生缺陷干预工程”选用产品的字样，是谁批准的？北京一位姓吉的消费者也提出同样的问题，他问：“国家允许产品包装与批准证书不相符的产品流通吗？不相符的产品是否可以继续食用？以国家机关推荐产品的名义做宣传是否妥当？是否可信？产品到底是原料进口还是原装进口？如果是原料进口，谁又加工成商品在市场流通的？其加工合法吗？卫生标准可靠吗？老百姓加工面条、大饼都要办卫生许可登记，更何况保健食品、孕妇专用产品。”



为了弄清消费者提出的这些问题，记者走访了卫生部、国家工商局和计生委等有关职能部门。



卫生部卫生监督中心的孙先生证实了消费者提出的“福施福”进口保健品批准证书上名称是福施福（营养素补充剂），卫生部没有批孕妇两字，“孕妇”是经销商自己加上去的。名称与批准证书不相符，违反了卫生部有关规定，他们要进一步调查核实查处。



国家工商局看了消费者全部投诉材料后回答说：该产品的确有商标标识不符、扩大宣传和违反《不正当竞争法》等违法违规行为，但要弄清情况还应该到产品属地广东省有关单位调查。



国家计生委科技司的叶小姐说：国家计生委确实实施了“出生缺陷干预工程”，“福施福”是当时的赞助单位，所以取得了冠名权，但并没有被推荐成为选用产品，国家“出生缺陷干预工程”没有推荐任何选用产品。叶小姐告诉记者，国家工商局就此事已经查询过计生委，他们答复都是一样的。



记者在广州出入境检验检疫局证实了“福施福”为原料进口后，来到了广东食品药品质量监督局核查“福施福”是否有国内加工企业，国内加工是否合法。经查询，广东食品药品质量监督局企业名录里根本没有“福施福”保健品，不但查不到国内加工企业，连中国总经销广州市福胜医药保健品有限公司都没有在此注册备案。



记者将“福施福”的问题反映给广东省工商局，得到的答复是：“福施福”商标标识不符、扩大宣传和违反了不正当竞争法等问题只能劝其整改。针对举报的消费者不是广州的，是北京、河北的，应由北京、河北的工商局管理，广州没有人投诉该产品，不在查处之列。据了解，广州日报2001年就以《领“准生证”为何搭售孕妇药》为题揭露过此事，而且记者亲眼看到目前“福施福”摆在广州药店的货架上还在销售。



记者拨通了“福施福”保健品中国总经销广州市福胜医药保健品有限公司的电话，一位姓朱的小姐以不知道、不清楚和正在办理回答了记者的提问。然后就是大讲该保健品的作用和该产品推向市场时的规模，并希望能正面报道。



卫生部早在2002年卫法监发251号《关于进一步深入开展保健食品标签、说明书监督检查工作的通知》就已明确规定，凡实际销售的保健食品标签、说明书与批准内容或报送备查材料不一致的，生产地所在省级卫生行政部门要根据有关规定予以查处，责令其停止生产经营，情节严重者应吊销其卫生许可证；自2003 年1月1日起，保健食品生产企业出厂保健食品的标签上必须标注省级卫生行政部门发放的生产卫生许可证文号，无文号的一律不得销售。《广告法》中也明确规定，广告不得使用国家机关和国家机关工作人员的名义。



据记者了解，像“福施福”这样商标不符、扩大宣传和违反了不正当竞争法的违法违规商品、药品在市场上很普遍。



《市场报》 (2004年08月24日 第六版)



================================



09年03月27日在国家食品药品监督管理局查询到的所有已经批准的进口保健食品列表：
网址： http://app1.sfda.gov.cn/datasearch/face3/dir.html

1.普诺牌谱诺阴片 (国食健字J20070008 法国普诺营养实验研究中心)

2.七海牌健儿宝鱼肝油 (卫食健进字(2000)第0002号 英国七海有限公司)

3.余仁生牌灵芝孢子胶囊 (国食健字J20070009 余仁生（香港）有限公司)

4.维士比液 (卫进食健字(1999)第026号 台湾三洋药品工业股份有限公司)

5.康力士牌三文鱼油维生素E软胶囊 (卫进食健字(1997)第037号 美国宝力士有限公司)

6.法尔诺德牌硒锌维片 (国食健字J20070010 丹麦法尔诺有限公司)

7.海贝特牌易贝安粉 (卫进食健字(1999)第032号 日本富士生物制品株式会社)

8.禄丰堂牌禄丰堂胶囊 (国食健字J20070011 德全高科技药业有限公司)

9.爱可力牌欣乐片 (卫食健进字(2002)第0003号 瑞克桑迪有限公司)

10.爱丽克丝牌爱丽克丝海波尔软胶囊 (国食健字J20080001 日本株式会社嘉斯蒂思)

11.中天生技牌维生素铁片 (国食健字J20080002 中天生物科技股份有限公司)

12.降脂能软胶囊 (卫进食健字(1998)第027号 威林研究制造公司)

13.澳然牌蜂胶软胶囊 (国食健字J20040021 澳大利亚天然健康产品有限公司)

14.瀚将牌八佰乐胶囊 (国食健字J20040040 上海翰将商贸有限公司)

15.百立乐牌牛初乳片 (国食健字J20040050 新西兰培芝有限公司)

16.百源堂牌燕窝川贝枇杷膏 (卫食健进字(2001)第0005号 关东百源堂（灵药德兴堂）联合药厂有限公司)

17.保宁牌高丽红参膏 (国食健字J20040011 BNN 有限公司)

18.鹰牌花旗参银杏叶茶 (卫进食健字(1999)第040号 健康元药业集团股份有限公司)

19.联邦牌健力片 (国食健字J20040024 福特咨询服务(武汉)有限公司)

20.美信钙+D片 (卫进食健字(1999)第015号 美信药业公司)

21.力维牌复合多维片(儿童型) (国食健字J20070005 维他命动力公司)

22.鹰牌花旗参清咽糖 (卫食健进字(2000)第0036号 -)

23.尤维斯牌角鲨烯软胶囊 (国食健字G20080699 万宁药业有限公司)

24.法尔诺德牌硒片 (国食健字J20070006 丹麦法尔诺有限公司)

25.博士伦博视康牌叶黄素片 (国食健字J20070004 德国博士曼大药厂（Dr.Mann Pharma）)

26.正官庄牌高丽参元饮品 (卫进食健字(1997)第044号 韩国人参公社)

27.正官庄牌高丽参软胶囊 (卫食健进字(2002)第0005号 韩国人参公社)

28.正官庄牌高丽参茶 (卫进食健字(1998)第023号 韩国人参公社)

29.正官庄牌高丽参粉 (卫食健进字(2002)第0001号 韩国人参公社)

30.康力士牌褪黑素片 (卫食健进字(1999)第0058号 美国宝力士有限公司)

31.康力士牌天然卵磷脂软胶囊 (卫食健进字(1999)第044号 美国宝力士有限公司)

32.达文奇牌福莱斯胶囊 (国食健字J20060004 美国纽康科技公司)

33.盈绰雅牌盈绰雅胶囊 (国食健字J20060006 天然维生素补充剂有限公司)

34.艾丽芙牌爱斯荷尔斯胶囊 (国食健字J20040010 美国爱斯乐夫生物科技有限公司)

35.安克牌欣静缬草片 (卫食健进字(2002)第0009号 德国爱博公司)

36.迪巧牌秀源女性片 (卫食健进字(2003)第0024号 美国安士制药公司)

37.傲滋牌钙片 (国食健字J20040036 奥斯比实业(深圳)有限公司)

38.傲滋牌维缔口服液 (国食健字J20040048 生物矿物元素公司)

39.日东牌益生维他片 (卫进食健字(1998)第067号 韩国日东制药株式会社)

40.红人归牌红人归胶囊 (国食健字J20050018 赛莱斯实验室有限公司)

41.三港牌欧克胶囊 (国食健字J20050007 美国花旗制药公司)

42.科瑞奇牌鲨鱼软骨生物提取液 (国食健字J20060007 加拿大雅典生物科技股份有限公司)

43.哈乐康牌左卡尼汀蛋白营养粉 (国食健字J20060012 德国哈乐康公司)

44.爱丽克丝牌爱丽克丝胶囊 (国食健字J20050017 株式会社 日本生物制剂)

45.健儿宝牌宝宝水 (卫食健进字(2002)第0008号 利来药业有限公司)

46.拉摩力拉牌玛卡片 (国食健字J20050014 赫赛尔公司)

47.康麦斯牌维芝鱼油胶囊 (国食健字J20060010 康龙集团公司)

48.健之力牌深海鲨肝油软胶囊 (国食健字J20050012 株式会社自然疗法协会)

49.福可达牌海藻口服液 (国食健字J20060005 株式会社F.CC堀内)

50.蜜泉牌澳洲尤加利蜂胶液 (国食健字J20050020 澳大利亚澳佳集团有限公司)

51.正官庄牌高丽参膏 (卫进食健字(1999)第020号 韩国人参公社)

52.正官庄牌高丽参吨饮品 (卫进食健字(1997)第039号 韩国人参公社)

53.海默飞牌复合铁片 (国食健字J20040054 瑞典倍铁发有限责任公司)

54.草苓香牌净康宝胶囊 (国食健字J20050016 大中华生物化学研究有限公司)

55.动力键牌丹心冲剂 (国食健字J20050004 CHS国际研究有限公司)

56.伊之选牌女士维生素及矿物质片 (国食健字J20050006 香港维特健灵健康产品有限公司)

57.联邦卡布牌卡布软胶囊 (国食健字J20050010 美国联邦制药有限公司)

58.雅培益力佳SRR营养配方粉 (国食健字J20050003 美国雅培制药有限公司)

59.天阳绿得康牌绿藻片 (国食健字J20050002 味丹企业股份有限公司)

60.爱基爱启牌莱福汉斯口服液 (国食健字J20050005 美国泰尔林健康技术有限公司)

61.卫康星牌卫康胶囊 (国食健字J20050011 维康力（国际）有限公司)

62.得美健牌葡萄籽胶囊 (国食健字J20050026 美国葛莱美有限公司)

63.多瑙河牌多瑙河饮料 (国食健字J20050021 瑞士神奇天然保健品公司)

64.畠中牌甲壳素片 (国食健字J20050019 日本畠中制药股份有限公司)

65.伊之选牌男士维生素及矿物质片 (国食健字J20050015 香港维特健灵健康产品有限公司)

66.新生命牌芦荟津胶囊 (国食健字J20040001 美国天然健康资源有限公司)

67.联邦牌健舒片 (国食健字J20040047 新生命资源药业集团有限公司（美国）)

68.联邦牌健生片 (国食健字J20040045 新生命资源药业集团有限公司（美国）)

69.美洲熊牌康宝钙软胶囊 (卫食健进字(2002)第0034号 美国华纳制药公司)

70.伊琦牌羊胎盘软胶囊 (国食健字J20040014 伊琦健康产品有限公司)

71.鹰牌高丽参胶囊 (卫进食健字(1998)第061号 )

72.鹰牌花旗参灵芝茶 (卫进食健字(1998)第062号 )

73.鹰牌花旗参川贝枇杷膏 (卫进食健字(1998)第033号 )

74.鹰牌花旗参胶囊 (卫进食健字(1997)第063号 )

75.鹰牌林活胶囊 (卫进食健字(1998)第034号 )

76.健宜富牌玉米凤梨酵素粉剂 (卫进食健字(1998)第057号 原本生化科技股份有限公司)

77.加营素R蛋白质粉 (国食健字J20040052 美国雅培制药有限公司Ross产品部)

78.美力生牌褪黑素片 (卫食健进字(2001)第0034号 美力生制药集团有限公司)

79.科蓉牌褪黑素胶囊 (卫进食健字(1998)第012号 美国杰富利有限公司)

80.力维牌美莱片 (国食健字J20060015 维他命动力公司)

81.正官庄牌高丽参精丸 (卫进食健字(1999)第021号 韩国人参公社)

82.明圣牌多元营养素片（孕妇用型） (国食健字J20040004 泰克沃德股份有限公司)

83.赛宝泰仕牌牛初乳粉 (国食健字J20040026 深圳市赛宝泰仕保健品有限公司)

84.赛宝泰仕牌牛初乳胶囊 (国食健字J20040027 深圳市赛宝泰仕保健品有限公司)

85.赛宝泰仕牌牛初乳咀嚼片 (国食健字J20040025 深圳市赛宝泰仕保健品有限公司)

86.鲨克牌牛磺酸饮料 (卫进食健字(1997)第038号 德恒裕有限公司)

87.深澳牌蜂胶浓缩液 (国食健字J20040041 澳大利亚麦曲兰药业保健品制造厂)

88.美力生牌磷脂软胶囊 (国食健字J20040034 美力生制药集团有限公司)

89.生源牌生源粉 (国食健字J20050027 艾禄爱株式会社)

90.世宝淳牌卡西通片 (国食健字J20040043 维他快斯特国际公司花园州营养公司)

91.世宝淳牌傲德福片 (国食健字J20040046 维他快斯特国际公司花园州营养公司)

92.仕丹孚牌仕丹孚胶囊 (国食健字J20040018 美国K.F集团)

93.双心牌双心口服液 (国食健字J20050001 德国魁士药业公司)

94.韩天牌高丽红参片 (国食健字J20040002 株式会社高丽红参公司)

95.天顺牌得贝特软胶囊 (国食健字J20040028 罗斯勒保健食品有限公司)

96.万邦牌比尔圣坚胶囊 (国食健字J20040013 美国万邦制药公司)

97.维素德牌维素德冲剂 (国食健字J20040044 西班牙凯他利丝公司)

98.马百良牌海宝胶囊 (国食健字J20060008 马百良药厂有限公司)

99.大阔海牌乡梦片 (国食健字J20040003 美国全天然保健食品公司)

100.美康牌力健胶囊 (国食健字J20040019 美国健康企业有限公司)

101.美力生牌芦荟软胶囊 (卫食健进字(2001)第0041号 青岛生命力保健品有限公司)

102.美力生牌深海鱼油软胶囊 (卫食健进字(2001)第0001号 青岛生命力保健品有限公司)

103.美力生牌液体钙软胶囊 (卫食健进字(2001)第0002号 美力生制药集团有限公司)

104.明圣牌多元营养素片（老年用型） (国食健字J20040005 泰克沃德股份有限公司)

105.明圣牌多元营养素片（男用型） (国食健字J20040008 泰克沃德股份有限公司)

106.明圣牌多元营养素片（女用型） (国食健字J20040006 泰克沃德股份有限公司)

107.明圣牌多元营养素片（乳母用型） (国食健字J20040007 泰克沃德股份有限公司)

108.康麦斯牌忆立清胶囊 (国食健字J20030001 康龙集团公司)

109.康麦斯牌芦荟软胶囊 (国食健字J20040042 康龙集团公司)

110.康麦斯牌深海鲨烯软胶囊 (国食健字J20040030 康龙集团公司)

111.康麦斯牌维生素A软胶囊 (国食健字J20040038 上海康麦斯保健品有限公司)

112.康麦斯牌维生素C片 (国食健字J20040012 康龙集团公司)

113.康麦斯牌维生素E软胶囊 (国食健字J20040037 上海康麦斯保健品有限公司)

114.康逆灵牌丽质胶囊 (国食健字J20030004 康逆灵药业有限公司)

115.沛缇牌康之源软胶囊 (国食健字J20060009 超能生化科技股份有限公司)

116.来托康牌番茄红素片 (国食健字J20040009 美国瑞琦公司)

117.力维牌多维咀嚼片(成人型) (国食健字J20070001 维他命动力公司)

118.力维牌番茄红素胶囊 (国食健字J20040051 维他命动力公司)

119.力维牌老人多维晶 (国食健字J20040033 深圳市力维生物科技有限公司)

120.联邦银丹牌健怡泡腾片 (国食健字J20040035 联邦制药厂有限公司)

121.灵达牌生命口服液 (卫食健进字(2000)第0001号 芭芭拉国际保健)

122.康沛蕾迪牌芦荟软胶囊 (国食健字J20030003 美国鲁滨逊制药有限公司)

123.爱德牌海豹油胶囊 (卫进食健字(1998)第059号 国际新技术发展有限公司)

124.正官庄牌高丽参胶囊 (卫进食健字(1999)第035号 韩国人参公社)

125.康麦斯牌丽多胶囊 (国食健字J20040023 美国康龙集团)

126.新生命牌深海鱼油胶囊 (卫食健进字(2001)第0032号 美国天然健康资源有限公司)

127.新生命牌大豆磷脂胶囊 (卫食健进字(2001)第0039号 美国天然健康资源有限公司)

128.金尼诗牌蜂胶软胶囊 (国食健字J20050008 金尼诗澳洲有限公司)

129.维体康牌维生素矿物质片(乳母型) (国食健字J20040017 美国生命与医学研究所)

130.维体康牌维生素矿物质片(孕晚期型) (国食健字J20040016 美国生命与医学研究所)

131.维体康牌维生素矿物质片(孕中期型) (国食健字J20040015 美国生命与医学研究所)

132.康麦斯牌牛初乳含片 (国食健字J20040022 康龙集团公司)

133.康麦斯牌伊能清胶囊 (国食健字J20040053 康龙集团公司)

134.康麦斯牌蜂胶胶囊 (国食健字J20040031 康龙集团公司)

135.康麦斯牌鱼油磷脂软胶囊 (国食健字J20040049 康龙集团公司)

136.合生元牌益生菌胶囊 (国食健字J20060002 法国拉曼公司)

137.汉生堂牌资癸女贞胶囊 (国食健字J20050023 汉生堂药业有限公司)

138.汉生堂牌资癸元阳胶囊 (国食健字J20050024 汉生堂药业有限公司)

139.高寿乐牌苦瓜复合片 (国食健字J20060011 美国GSL科技公司)

140.葆苾康牌形体塑片 (国食健字G20060607 美国雷纳健康有限公司)

141.洪达敏牌洪达敏胶囊 (卫食健进字(1999)第0046号 韩国联合制药株式会社)

142.纽崔莱钙镁片 (卫进食健字(1997)第026号 安利（中国）日用品有限公司)

143.庆余牌润晶胶囊 (国食健字J20060016 美国加州复生药厂)

144.民生普瑞宝牌益生菌颗粒 (国食健字J20060014 拉曼公司)

145.普诺牌普诺阳片 (国食健字J20070003 法国普诺营养实验研究中心)

146.博特力牌博特力胶囊 (国食健字J20060001 东林生物医学研究公司)

147.帝比爱金牌海豹油软胶囊 (国食健字J20040029 帝比爱工业公司)

148.新东科牌威尔圣达胶囊 (国食健字J20050013 美国威尔斯制药公司)

149.苏威牌爱蜜维糖浆 (国食健字J20070002 苏威制药)

150.炳翰牌人参粉 (国食健字J20050025 炳翰制药厂股份有限公司)

151.参寿惠牌人参果软胶囊 (卫食健进字(1999)第0069号 I.T.B.S株式会社)

152.草苓香牌保尔健胶囊 (国食健字J20060003 大中华生物化学研究有限公司)

153.超力康牌超力康胶囊 (国食健字J20030002 美国拜欧-超力康制药企业)

154.纯清牌实力品胶囊 (国食健字J20040039 美国自然营养品中心)

155.大阔海牌深海鱼油胶囊 (国食健字J20040020 美国全天然营养制药总厂)

156.法尔诺德牌辅酶Q10软胶囊 (国食健字J20060013 丹麦法尔诺有限公司)

157.格灵凡力牌午后清胶囊 (国食健字J20040032 纽约康逆灵药业有限公司)

158.正官庄牌高丽参含片 (卫进食健字(1999)第022号 韩国人参公社)

159.海心宝牌海豹油软胶囊 (卫食健进字(2001)第0010号 加拿大卡巴特海洋食品有限公司)

160.花旗牌洋参袋泡茶 (国食健字G20060781 太平健康品（汕头）有限公司)

161.金尼诗牌蜂皇浆软胶囊 (国食健字J20050009 金尼诗澳洲有限公司)

162.宝维尔牌宝维尔胶囊 (国食健字J20050022 德国BKV有限责任公司)

163.大汉美梦得宁片 (卫进食健字(1999)第019号 威林研究制造公司)

164.东佑牌鱼油软胶囊 (国食健字J20080003 韩国东佑产业)

165.东方红牌川贝桔梗枇杷膏（无糖配方） (国食健字J20080005 正美药品有限公司)

166.未字牌流健颗粒 (国食健字J20080006 健康社有限公司)

167.香江澳美牌藤柏胶囊 (国食健字J20080004 澳美制药厂)

168.尤维斯牌鱼油软胶囊 (国食健字G20080274 万宁药业有限公司)

169.尤维斯牌蒜宝软胶囊 (国食健字G20080275 万宁药业有限公司)

170.尤维斯牌鲨鱼软骨胶囊 (国食健字G20080273 万宁药业有限公司)

171.尤维斯牌鲑鱼油软胶囊 (国食健字G20080272 万宁药业有限公司)

172.尤维斯牌维生素CE片 (国食健字G20080269 万宁药业有限公司)

173.尤维斯牌芦荟软胶囊 (国食健字G20080265 万宁药业有限公司)

174.尤维斯牌螺旋藻片 (国食健字G20080267 万宁药业有限公司)

175.尤维斯牌褪黑素片 (国食健字G20080271 万宁药业有限公司)

176.尤维斯牌大豆磷脂软胶囊 (国食健字G20080270 万宁药业有限公司)

177.尤维斯牌钙D片 (国食健字G20080266 万宁药业有限公司)

178.尤维斯牌钙D软胶囊 (国食健字G20080268 万宁药业有限公司)

179.尤维斯牌膳食纤维素片 (国食健字G20080282 万宁药业有限公司)

180.尤维斯牌多维口嚼片(儿童型) (国食健字G20080279 万宁药业有限公司)

181.尤维斯牌钙片(儿童型) (国食健字G20080283 万宁药业有限公司)

182.尤维斯牌鱼蛋白蔷薇片 (国食健字G20080284 万宁药业有限公司)

183.尤维斯牌西洋参胎盘软胶囊 (国食健字G20080280 万宁药业有限公司)

184.尤维斯牌鱼油磷脂软胶囊 (国食健字G20080281 万宁药业有限公司)

185.香江澳美牌羊藿参花胶囊 (国食健字J20080008 澳美制药厂)

186.维维达牌伊维片 (国食健字J20080007 芬兰唯美芳华有限公司)

187.阿明诺牌美丝康亭胶囊 (国食健字J20080009 日本阿明诺化学株式会社)

188.天然培旦陞牌蜂胶液 (国食健字J20080011 斯达瑞吉进出口贸易有限公司)

189.真参纳牌红参胶囊 (国食健字J20080010 法摩克罗斯有限公司)

190.华纳安迪牌安迪胶囊 (卫食健进字(2002)第0042号 美国华纳制药公司)

191.康麦斯牌归芪胶囊 (国食健字J20080012 康龙集团公司)

192.京都念慈菴R灵芝洋参蜜膏 (国食健字J20080013 京都念慈菴总厂有限公司)

193.盈绰雅牌盈绰雅胶囊 (国食健字J20060006 玛莲营养药剂制品有限公司)

194.山田养蜂场牌人参蜂胶液 (国食健字J20080014 株式会社山田养蜂场)

195.菠劳菲牌联众含片 (国食健字J20080016 新帝国（Nutrilo）公众健康与科技保健食品有限公司)

196.卫存牌卡布莱斯片 (国食健字J20080015 美国尤尼法恩联合制药公司)

197.保力达牌保力达口服液 (国食健字J20080019 保力达股份有限公司)

198.瑞福瑞牌辅酶Q10胶囊 (国食健字J20080017 美国制药百福生公司)

199.山田养蜂场牌峰胶软胶囊 (国食健字J20080018 株式会社山田养蜂场)

==================================
从福施福（英文名：Forceval Capsules )看我国食品卫生审查制度的缺陷。



国家审批的保健食品有2种批号：卫食健字与国食健字。究竟这两种字号的区别在哪里？


卫食健字和国食健字是保健食品在不同时期分别由卫生部和国家食品药品监督管理局批准的产品批准文号，卫食健字是国家卫生部2003年前期的批准号，自2004年国家成立了食品药品管理监督局后，卫食健字号一律要重新审批转为国食品健字号。



根据2005年由国家食品药品监督管理局颁布的《保健食品注册管理办法（试行）》中的第二章第二节第三十三条 规定，保健食品批准证书有效期为5 年。国产保健食品批准文号格式为：国食健字G＋4位年代号＋4位顺序号；进口保健食品批准文号格式为：国食健字J＋4位年代号＋4位顺序号。




福施福经中华人民共和国卫生部批准，批准文号：卫进食健字[1998]第009号 是中国优生科学协会推荐产品, 是国家计划生育委员会科技司"出生缺陷干预工程"指定产品 （福施福 产品质量，由中国人民保险公司承保)

孕前服用



1，什么是食品

       可以当饭吃，虽说某种东西吃多了不好。但是吃上半斤，应当不会危害到健康。



http://emc.medicines.org.uk/medicine/16016/SPC/Forceval+Capsules/


发帖者 时间： 没有评论:

2009年3月12日星期四

得怪病儿子颅骨被摘除 为求医家人变卖房产






得怪病儿子颅骨被摘除 为求医家人变卖房产(图)


2009-03-13 03:53:58　来源: 北京晨报(北京)　跟帖 818 条

核心提示：山东莒县一农村小孩从小被诊断患有顽固性癫痫病，连续做三次开颅手术，花费近20万元，家里为此变卖房子和地里作物。但由于手术后伤口感染，孩子半边颅骨被迫摘除。目前，身在北京的他和父亲，因欠医院十余万治疗费，已不能继续住院，只好流落街头。





开心的小国柱还不知今后的艰难。

北京晨报3月13日报道 昨日，30多岁的侯晓峰抱着刚满8岁的儿子坐在堆满餐具和衣物的纸箱旁，看着路上过往的行人，眼里噙泪。孩子从小就患上了一种极其罕见的癫痫病，右脑半球被完全切除。因欠医院十余万元的治疗费用，他已不能继续住院。而为了治疗孩子的病卖掉房产的他如今不知还能去往何方。


昨日上午，海淀区北京三博脑科医院对面一条狭长的胡同里，一位男子蹲坐在墙角，面容憔悴，他就是侯晓峰。他怀里是8岁的儿子侯国柱。小国柱头戴一顶毛线帽子，摘下帽子，眼前的景象让人触目惊心。他眉骨以上的右脑部分已经消失，只剩下左半球，干瘪的头皮上有大块伤疤。


侯晓峰一家住在山东省莒县农村。2001年，妻子为他生下了一对双胞胎儿子，分别取名为侯国
梁和侯国柱。与健康的哥哥侯国梁不同的是，弟弟侯国柱被断定患有顽固性癫痫病。2006年4月，侯晓峰带着小国柱来到北京三博脑科医院，最后确诊为
Rasmussen’s脑炎，一种极其罕见且治疗难度很大的病症。侯国柱在此做了三次开颅手术，家里花费了近20万元。侯晓峰为此已变卖了老家所有的房子
和地里的作物，但仍欠医院十余万元治疗费用。


提起小国柱，医院的工作人员印象深刻。据他们介绍，侯国柱的治疗非常成功，手术之后癫痫症状几乎消除，但由于术后一段出院期间，刀口缝合处感染扩散，孩子半边颅骨被迫摘除。


侯晓峰说，他现在已经无家可归。昨日，一位好心路人留宿了他们一晚，但并未留名。他说，有很多人帮助过自己，他都一一记在小本子上，“有朝一日我一定要报答他们。”



(本文来源：北京晨报 作者：刘奕诗 吴宁)
jiangtao


发帖者 时间： 没有评论:

2009年3月8日星期日

致招商银行的公开信








致招商银行的公开信


作者：徐继哲


2007年1月25日 北京



多
年以来，我一直都是招商银行的用户，同时也在一直忍受着招商银行不平等的网上银行服务。众所周知，无论是什么网络服务，都要遵循互联网的行业标准和技术标
准。可是不知为何，招商银行的网上银行服务却没有遵守W3C等互联网标准，而是采用了微软公司的专有软件技术，ActiveX。采用微软的专有软件技术提
供公共网上银行服务意味着什么？这意味着用户只有使用微软专有的IE（Internet
Explorer）浏览器才能正常使用招商银行的网上银行服务；这意味着用户在使用网上银行时，招商银行将用户限制在了专有的、昂贵的、漏洞百出的专有软
件Microsoft Windows上；这意味着招商银行极大地提高了用户使用网上银行的成本，因为用户只有花费上千元人民币购买Microsoft
Windows操作系统才能使用招商银行的网上银行；这意味着像我这样只使用GNU/Linux、*BSD、Firefox（大量的Windows用户也
在使用Firefox）的大量自由软件用户无法正常使用我们应得的网上银行服务；这意味着招商银行正在不公平地对待每一位用户，正在歧视一切非微软用户。



现
在，作为一名招商银行用户和自由软件用户，我请求招商银行采用符合W3C、RFC等开放的、自由的互联网标准来提供网上银行服务。使用开放的、自由的标准
意味着每个人都可以使用你的服务，无论他使用的是专有软件还是自由软件；意味着招商银行平等对待每一位用户；意味着招商银行真的有能力“因您而变”；意味
着现有的自由软件用户会继续使用招商银行，而不是转投其他银行。



虽然使用ActiveX专有软件技术来提供公众服务是错误的，但
我们也能看到招商银行的动机是好的：试图保障用户的帐户安全。在技术方面，ActiveX是微软专有的、过时的、兼容性极差的技术，任何采用
ActiveX的网站都是人为地给用户引入一个潜在的入侵通道，为用户埋下了一个地雷。最近也有很多网友在讨论现有招商银行网上银行的安全隐患，比如：直
接采用了某个可公开下载的二进制动态库文件，在发行自己的软件的时候没有做数字签名，这种低级的技术手段直接导致了用户的电脑可能被植入木马，等等。可是
我们根本没有必要讨论现有的技术实现是否安全。为什么？因为招商银行解决安全问题的思路是完全错误的，所以即使是安全的，我们也不能接受。任何以提供某种
服务为借口强行或偷偷地向用户的计算机安装各类插件的行为都是流氓行为，我们有必要讨论流氓行为的安全性吗？非计算机专业用户可以通过招商很行宾馆的故事了解招商银行解决安全问题的思路对于用户来说是多么的不方便、不友好和荒谬。



当
今社会，只有那些拥有强烈社会责任感的公司才能真正赢得用户。对于我们这样的发展中国家，普通老百姓实在无力购买昂贵的专有软件，比如微软的
Windows操作系统，而自由软件为我们提供了另外一种选择，无论对于个人还是国家都是如此。经历了24年（1983年－2007年）的努力，自由软件
运动早已开花结果，在计算机工业、科学研究、教育、法律等领域都取得了巨大的成功，自由软件赋予了每个人运行、学习、修改和再发行软件的自由（参阅《Richard Stallman和自由软件运动》，
进一步了解自由软件运动）。现在，使用自由软件可以完成生活、工作中的各类任务，从构建服务器集群到个人计算机桌面，几乎无所不能。所以越来越多的计算机
厂商开始预装GNU/Linux，而不是微软的Windows，越来越多的用户开始选择使用以GNU/Linux、*BSD、Firefox等为代表的自
由软件。这不但显著地降低了成本，还获得了使用计算机的自由度。可是由于本文谈论的技术问题，现在自由软件用户却无法正常使用招商银行的网上银行服务。当
然招商银行也能找到许多继续不支持自由软件用户的理由，那么这必将促使一部分自由软件用户转移到其他的采用互联网技术标准的网上银行。更为严重的是将迫使
很多人走向盗版市场或者妨碍正在饱受盗版专有软件良心拷问的用户转换到自由软件上来，大家的无奈选择必将潜移默化地降低社会总体法律意识，最后都认为用盗
版软件是很正常的。所以，如果招商银行继续固执地使用ActiveX等专有软件技术，那么将引导大家甚至整个社会开始依赖某种专有软件技术，依赖某一家公
司，带领大家进入了某家公司的圈套，直到用户由于使用盗版软件被起诉，这是多么危险的趋势啊！



最近在韩国发生了这样的事情，
韩国的很多网站，比如：网络门户、电子商务、游戏、银行，甚至政府的网站都大量采用了ActiveX技术，最近微软就要发布Vista操作系统，结果发生
了什么呢？已经有很多计算机厂商开始预装Vista操作系统，也有大量用户计划升级到Vista系统，可是经过测试，如果用户使用Vista操作系统，那
么将无法正常使用现有的这些网络服务，无法正常访问网上银行，无法正常获取信息，无法正常访问政府的网站，很多以前可以顺利完成的操作现在一下子都无法做
了。这是因为微软最新发布的Vista操作系统与这些ActiveX插件不兼容，导致现有功能全部失效。韩国官方已经意识到了问题的严重性，同时很多网站
正在微软公司的帮助下解决这个问题。亲爱的朋友，请想想，一个国家的正常运转要依赖某家外国公司，这不怕么？这不荒谬么？这不就是数字殖民吗？所以，我们
也要引以为戒，不要在专有软件技术上构建虚假的繁荣，最终却落入他人的圈套。我们的未来要掌握在自己的手里，而不是微软们！



我相
信有很多朋友有过同样的遭遇和看法，并在不同的场合表达过自己的心声。现在，无论你是GNU/Linux用户，比如：gNewSense、Debian、
gentoo、ubuntu、SUSE、Mandriva等GNU/Linux发行版用户，还是FreeBSD/NetBSD/OpenBSD
/DragonFlyBSD/Darwin/Mac OS
X用户，还是Windows下的饱受IE安全漏洞困扰转而使用Firefox的用户，还是正在被迫使用盗版Windows专有软件、饱受道德诘难的用户，
我呼吁大家团结起来，一起大声疾呼：“请求招商银行采用开放的、自由的互联网标准提供网上银行服务，平等地对待每一个用户！”。作为正式的意见收集渠道，
请将“你自己的”《致招商银行的公开信》通过邮件发到info@zeuux.org，哲思社区将收集、汇总、发布大家的公开信，并将收到的部分邮件打印出来，正式交给招商银行。在大家撰写公开信的时候，请使用纯文本格式，我们不接受Microsoft Office等专有格式。



网
上银行是一项重要的社会服务，所以我们要严肃地看待这个问题。请招商银行能够对此公开行动在招商银行的网站上给出公开的、明确的、正式的答复，以及解决问
题的时间表。如果招商银行要继续一意孤行，继续不平等地对待每一个用户，那么用户也可以做出自己的选择，毕竟换个银行和换个旅馆一样方便。在呼吁大家更换
到支持开放标准的银行之前，我期待着招商银行的“因您而变”！期待能够和招商银行一起解决这个问题！



最后，我呼吁招商银行采用自由的、开放的标准，提供跨平台的网上银行服务，平等对待每一位用户！





发帖者 时间： 没有评论:

2009年3月3日星期二

要学习的课程




































世界牛校 分步式系统 相关课程：
http://net.pku.edu.cn/~course/cs501/2008/schedule.html

http://www.cs.ucla.edu/~kohler/class/08w-dsi/
http://www.ece.ubc.ca/~matei/EECE411/

6.824: Distributed Systems

http://pdos.csail.mit.edu/6.824/schedule.html

http://www.cogs.susx.ac.uk/courses/dist-sys/dist-sys.html

http://www.cs.cornell.edu./courses/cs5410/2008fa/

http://pages.cs.wisc.edu/~dusseau/Classes/CS739/

Cloud computing: Infrastructure, Services, and Applications
http://www.cs.berkeley.edu/~istoica/classes/cs294/09/

数学之美 系列一 统计语言模型


数学之美 系列二 谈谈中文分词


数学之美 系列三 隐含马尔可夫模型在语言处理中的应用


数学之美
系列四 怎样度量信息?


数学之美 系列五 简单之美：布尔代数和搜索引擎的索引


数学之美 系列六 图论和网络爬虫 (Web Crawlers)


数学之美 系列七 信息论在信息处理中的应用


数学之美 系列八 贾里尼克的故事和现代语言处理


数学之美 系列九 如何确定网页和查询的相关性


数学之美 系列十 有限状态机和地址识别


数学之美 系列十一 Google 阿卡 47 的制造者阿米特.辛格博士


数学之美
系列十二 余弦定理和新闻的分类


数学之美 系列十三 信息指纹及其应用


数学之美 系列十四 谈谈数学模型的重要性


数学之美 系列十五 繁与简 自然语言处理的几位精英


数学之美 系列十六 （上）不要把所有的鸡蛋放在一个篮子里 谈谈最大熵模型


数学之美 系列十六 （下）不要把所有的鸡蛋放在一个篮子里 谈谈最大熵模型


数学之美 系列十七 闪光的不一定是金子 谈谈搜索引擎作弊问题(Search Engine Anti-SPAM)


数学之美 系列十八 矩阵运算和文本处理中的分类问题


数学之美 系列十九 马尔可夫链的扩展 贝叶斯网络 (Bayesian Networks)


数学之美 系列二十 自然语言处理的教父 马库斯


数学之美 系列二十一 布隆过滤器（Bloom Filter）

数学之美
二十二 由电视剧《暗算》所想到的 &mdash; 谈谈密码学的数学原理

数学之美 系列二十三 输入一个汉字需要敲多少个键 — 谈谈香农第一定律


数学之美 系列二十四 从全球导航到输入法——谈谈动态规划


Internet数学
http://www.internetmathematics.org/

发帖者 时间： 没有评论:

2009年3月1日星期日

Dell 四次更换主板记






Dell 四次更换主板记

型号：D620。  
服务编号：3JHZ42X

 2007年4月开始使用。

2007年底：显示器花屏，打Dell工程师，确定为显卡故障,更换主板.

2008年02月25日，Dell D620 显示器无显示，打Dell工程师，确定为显卡故障。后更换主板

2008年12月30日：Dell D620 显示器无显示，打Dell工程师，确定为显卡故障。31日，更换主板。后使用中发现网卡无故丢包，经常打不开网页。而同局域网的另外一台可以飞速打开网页。

2009年3月2日：Dell D620 显示器无显示，打Dell工程师，确定为显卡故障。


同一款型号，4次均是同一故障，从概率论的角度，是偶然事件的概率很小。这只能说明：Dell的主板设计有先天性缺陷。
另外我在 SINA Blog写的帖子，被无故删除了。难道新浪收了Dell的好处？



发帖者 时间： 没有评论:
订阅： 博文 (Atom)