The Erlang way - dynamic upgrade of a server and UBF extensions
Tue Apr 29 10:44:22 CEST 2003
I want to add some things to UBF so we can make fault-tolerent
systems. This can be done with only a little change to UBF. I havn't
thought out all the details so I thought I'd try the idea out first.
All comments are welcome.
The UBF extensions provide an alternative solution to the problem
of dynamically upgrading or migrating a server or of dynamically
Firstly a bit of philosophy
The Erlang way
1) everything is a process
2) processes communicate by message passing
3) processes obey protocols
4) errors are handled non locally
Should I add more points?
UBF describes (specifies) 3) above
Extensions to UBF
A) ? (a undefined type) - to denote absence of an argument
B) The protocol versioning tag
C) The next IP word.
A) Undefined Type
Just use ? in UBF(A) to denote a missing value (easy)
B) + C)
Client UBF packets to a server should begin
| VersionNumber | ... rest of packet |
And server replies should begin
| VersionNumber | NextIP | ... rest of packet |
B) Protocol versioning
The version number is an integer 1 2 3 ... etc.
This is to allow dynamic upgrade of services
I have not thought out all the details but the idea is this:
Assume that a client has versions 1,2,3,6,8,10,11 of some software
The server speaks versions 1,2,3,4,5,9,10,14
At the start of the session we enter "protocol negotiation mode"
Both sides agree that version 10 is the highest common version of the
protocol that they both understand.
A session starts at level 10.
The client S/W crashes - this is detected by the client SW
The next message it sends to the server is a version 8 message
The server realizes that something has gone wrong - it cannot handle
version 8 messages - so they go back into protocol negotiation mode.
They agree on version 3 and continue.
This should allow "dynamic introduction of new services" with fallback to
previous versions if things go wrong.
C) Next IP
This is to allow dynamic migration of services.
There are two basic approaches to making things reliable. I'd like
to suggest a third.
The two common methods are:
1) Fixed server IP
The server has a fixed IP. To make things fault-tolerant the fixed IP is the
IP of a switch - the switch dispatches the request to a back-end.
(This is the common cluster solution - the switch is big and
expensive and can act as a front-end to many back-end servers)
2) Two fixed IP's
This is the DNS solution. My machine has two addresses for DNS - I try the
first, if it is broken I try the second.
I propose a third method: Each packet contains a NextIP field. This is
the address where the Next message should be sent.
Example. I have a server at 127.45.67.223
a) The client connects to 127.45.67.223
b) Client and server exchange messages
The server becomes heavily loaded, or, the operator wants to take the
server out of operation.
At some point the client receives a rpc reply with a NEW IP address
(not 127.45.67.223) but something different.
The client closes the connection to 127.45.67.223 connects to the new
address and carries on.
I think that B) + C) above would solve a lot of problems.
More information about the erlang-questions