The I/O-protocol in Erlang specifies a way for a client to communicate with an io_server and vice versa. The io_server is a process handling the requests and that performs the requested task on i.e. a device. The client is any Erlang process wishing to read or write data from/to the device.
The common I/O-protocol has been present in OTP since the beginning, but has been fairly undocumented and has also somewhat evolved over the years. In an addendum to Robert Virdings rationale the original I/O-protocol is described. This document describes the current I/O-protocol.
The original I/O-protocol was simple and flexible. Demands for spacial and execution time efficiency has triggered extensions to the protocol over the years, making the protocol larger and somewhat less easy to implement than the original. It can certainly be argumented that the current protocol is to complex, but this text describes how it looks today, not how it should have looked.
The basic ideas from the original protocol still holds. The io_server and client communicate with one single, rather simplistic protocol and no server state is ever present in the client. Any io_server can be used together with any client code and client code need not be aware of the actual device the io_server communicates with.
As described in Roberts paper, servers and clients communicate using io_request/io_reply tuples as follows:
{io_request, From, ReplyAs, Request}
{io_reply, ReplyAs, Reply}
The client sends an io_request to the io_server and the server eventually sends a corresponding reply.
When an io_server receives an io_request, it acts upon the actual Request part and eventually sends an io_reply with the corresponding Reply part.
To output characters on a device, the following Requests exist:
{put_chars, Encoding, Characters}
{put_chars, Encoding, Module, Function, Args}
The server replies to the client with an io_reply where the Reply element is one of:
ok
{error, Error}
For backward compatibility the following Requests should also be handled by an io_server (these messages should not be present after R15B of OTP):
{put_chars, Characters}
{put_chars, Module, Function, Args}
These should behave as {put_chars, latin1, Characters} and {put_chars, latin1, Module, Function, Args} respectively.
To read characters from a device, the following Requests exist:
{get_until, Encoding, Prompt, Module, Function, ExtraArgs}
Module, Function, ExtraArgs denotes a function and arguments to determine when enough data is written. The function should take two additional arguments, the last state, and a list of characters. The function should return one of:
{done, Result, RestChars}
{more, Continuation}
The Result can be any Erlang term, but if it is a list(), the io_server may convert it to a binary() of appropriate format before returning it to the client, if the server is set in binary mode (see below).
The function will be called with the data the io_server finds on it's device, returning {done, Result, RestChars} when enough data is read (in which case Result is sent to the client and RestChars are kept in the io_server as a buffer for subsequent input) or {more, Continuation}, indicating that more characters are needed to complete the request. The Continuation will be sent as the state in subsequent calls to the function when more characters are available. When no more characters are available, the function shall return {done,eof,Rest}. The initial state is the empty list and the data when an end of file is reached on the device is the atom 'eof'. An emulation of the get_line request could be (inefficiently) implemented using the following functions:
-module(demo).
-export([until_newline/3, get_line/1]).
until_newline(_ThisFar,eof,_MyStopCharacter) ->
{done,eof,[]};
until_newline(ThisFar,CharList,MyStopCharacter) ->
case lists:splitwith(fun(X) -> X =/= MyStopCharacter end, CharList) of
{L,[]} ->
{more,ThisFar++L};
{L2,[MyStopCharacter|Rest]} ->
{done,ThisFar++L2++[MyStopCharacter],Rest}
end.
get_line(IoServer) ->
IoServer ! {io_request, self(), IoServer, {get_until, unicode, '',
?MODULE, until_newline, [$\n]}},
receive
{io_reply, IoServer, Data} ->
Data
end.
Note especially that the last element in the Request tuple ([$\n]) is appended to the argument list when the function is called. The function should be called like apply(Module, Function, [ State, Data | ExtraArgs ]) by the io_server
A defined number of characters is requested using this Request:
{get_chars, Encoding, Prompt, N}
A single line (like in the example above) is requested with this Request:
{get_line, Encoding, Prompt}
Obviously, get_chars and get_line could be implemented with the get_until request (and indeed was originally), but demands for efficiency has made these additions necessary.
The server replies to the client with an io_reply where the Reply element is one of:
Data
eof
{error, Error}
For backward compatibility the following Requests should also be handled by an io_server (these messages should not be present after R15B of OTP):
{get_until, Prompt, Module, Function, ExtraArgs}
{get_chars, Prompt, N}
{get_line, Prompt}
These should behave as {get_until, latin1, Prompt, Module, Function, ExtraArgs}, {get_chars, latin1, Prompt, N} and {get_line, latin1, Prompt} respectively.
Demands for efficiency when reading data from an io_server has not only lead to the addition of the get_line and get_chars requests, but has also added the concept of io_server options. No options are mandatory to implement, but all io_servers in the Erlang standard libraries honor the 'binary' option, which allows the Data in the io_reply to be binary instead of in list form when possible. If the data is sent as a binary, Unicode data will be sent in the standard Erlang unicode format, i.e. UTF-8 (note that the function in get_until still gets list data regardless of the io_server mode).
Note that i.e. the
An I/O-server in binary mode will affect the data sent to the client, so that it has to be able to handle binary data. For convenience, it is possible to set and retrieve the modes of an io_server using the following I/O-requests:
{setopts, Opts}
As an example, the io_server for the interactive shell (in group.erl) understands the following options:
{binary, bool()} (or 'binary'/'list')
{echo, bool()}
{expand_fun, fun()}
{encoding, 'unicode'/'latin1'} (or 'unicode'/'latin1')
- of which the 'binary' and 'encoding' options are common for all io_servers in OTP, while 'echo' and 'expand' is valid only for this io_server. It's worth noting that the 'unicode' option notifies how characters are actually put on the physical device, i.e. if the terminal per se is unicode aware, it does not affect how characters are sent in the I/O-protocol, where each request contains encoding information for the provided or returned data.
The server should send one of the following as Reply:
ok
{error, Error}
An error (preferably enotsup) is to be expected if the option is not supported by the io_server (like if an 'echo' option is sent in a setopt Request to a plain file).
To retrieve options, this message is used:
getopts
The 'getopts' message requests a complete list of all options supported by the io_server as well as their current values.
The server replies:
OptList
{error,Error}
The Request element can in itself contain several Requests by using the following format:
{requests, Requests}
The server can for a list of requests send any of the valid results in the reply:
ok
{ok, Data}
{ok, Options}
{error, Error}
- depending on the actual requests in the list.
The following I/O request is optional to implement and a client should be prepared for an error return:
{get_geometry, Geometry}
The server should send the Reply as:
{ok, N}
{error, Error}
If an io_server encounters a request it does not recognize (i.e. the io_request tuple is in the expected format, but the actual Request is unknown), the server should send a valid reply with the error tuple:
{error, request}
This makes it possible to extend the protocol with optional messages and for the clients to be somewhat backwards compatible.
An io_server is any process capable of handling the protocol. There is no generic io_server behavior, but could well be. The framework is simple enough, a process handling incoming requests, usually both io_requests and other device-specific requests (for i.e. positioning , closing etc.).
Our example io_server stores characters in an ets table, making up a fairly crude ram-file (it is probably not useful, but working).
The module begins with the usual directives, a function to start the server and a main loop handling the requests:
-module(ets_io_server).
-export([start_link/0, init/0, loop/1, until_newline/3, until_enough/3]).
-define(CHARS_PER_REC, 10).
-record(state, {
table,
position, % absolute
mode % binary | list
}).
start_link() ->
spawn_link(?MODULE,init,[]).
init() ->
Table = ets:new(noname,[ordered_set]),
?MODULE:loop(#state{table = Table, position = 0, mode=list}).
loop(State) ->
receive
{io_request, From, ReplyAs, Request} ->
case request(Request,State) of
{Tag, Reply, NewState} when Tag =:= ok; Tag =:= error ->
reply(From, ReplyAs, Reply),
?MODULE:loop(NewState);
{stop, Reply, _NewState} ->
reply(From, ReplyAs, Reply),
exit(Reply)
end;
%% Private message
{From, rewind} ->
From ! {self(), ok},
?MODULE:loop(State#state{position = 0});
_Unknown ->
?MODULE:loop(State)
end.
The main loop receives messages from the client (which might be using the io-module to send requests). For each request the function request/2 is called and a reply is eventually sent using the reply/3 function.
The "private" message {From, rewind} results in the current position in the pseudo-file to be reset to 0 (the beginning of the "file"). This is a typical example of device-specific messages not being part of the I/O-protocol. It is usually a bad idea to embed such private messages in io_request tuples, as that might be confusing to the reader.
Let's look at the reply function first...
reply(From, ReplyAs, Reply) ->
From ! {io_reply, ReplyAs, Reply}.
Simple enough, it sends the io_reply tuple back to the client, providing the ReplyAs element received in the request along with the result of the request, as described above.
Now look at the different requests we need to handle. First the requests for writing characters:
request({put_chars, Encoding, Chars}, State) ->
put_chars(unicode:characters_to_list(Chars,Encoding),State);
request({put_chars, Encoding, Module, Function, Args}, State) ->
try
request({put_chars, Encoding, apply(Module, Function, Args)}, State)
catch
_:_ ->
{error, {error,Function}, State}
end;
The Encoding tells us how the characters in the message are represented. We want to store the characters as lists in the ets-table, so we convert them to lists using the unicode:characters_to_list/2 function. The conversion function conveniently accepts the encoding types unicode or latin1, so we can use the Encoding parameter directly.
When Module, Function and Arguments are provided, we simply apply it and do the same thing with the result as if the data was provided directly.
Let's handle the requests for retrieving data too:
request({get_until, Encoding, _Prompt, M, F, As}, State) ->
get_until(Encoding, M, F, As, State);
request({get_chars, Encoding, _Prompt, N}, State) ->
%% To simplify the code, get_chars is implemented using get_until
get_until(Encoding, ?MODULE, until_enough, [N], State);
request({get_line, Encoding, _Prompt}, State) ->
%% To simplify the code, get_line is implemented using get_until
get_until(Encoding, ?MODULE, until_newline, [$\n], State);
Here we have cheated a little by more or less only implementing get_until and using internal helpers to implement get__chars and get_line. In production code, this might be to inefficient, but that of course depends on the frequency of the different requests. Before we start actually implementing the functions put_chars/2 and get_until/5, lets look into the few remaining requests:
request({get_geometry,_}, State) ->
{error, {error,enotsup}, State};
request({setopts, Opts}, State) ->
setopts(Opts, State);
request(getopts, State) ->
getopts(State);
request({requests, Reqs}, State) ->
multi_request(Reqs, {ok, ok, State});
The get_geometry request has no meaning for this io_server, so the reply will be {error, enotsup}. The only option we handle is the binary/list option, which is done in separate functions.
The multi-request tag (requests) is handled in a separate loop function applying the requests in the list one after another, returning the last result.
What's left is to handle backward compatibility and the file-module (which uses the old requests until backward compatibility with pre-R13 nodes is no longer needed). Note that the io_server will not work with a simple file:write if these are not added:
request({put_chars,Chars}, State) ->
request({put_chars,latin1,Chars}, State);
request({put_chars,M,F,As}, State) ->
request({put_chars,latin1,M,F,As}, State);
request({get_chars,Prompt,N}, State) ->
request({get_chars,latin1,Prompt,N}, State);
request({get_line,Prompt}, State) ->
request({get_line,latin1,Prompt}, State);
request({get_until, Prompt,M,F,As}, State) ->
request({get_until,latin1,Prompt,M,F,As}, State);
Ok, what's left now is to return {error, request} if the request is not recognized:
request(_Other, State) ->
{error, {error, request}, State}.
Let's move further and actually handle the different requests, first the fairly generic multi-request type:
multi_request([R|Rs], {ok, _Res, State}) ->
multi_request(Rs, request(R, State));
multi_request([_|_], Error) ->
Error;
multi_request([], Result) ->
Result.
We loop through the requests one at the time, stopping when we either encounter an error or the list is exhausted. The last return value is sent back to the client (it's first returned to the main loop and then sent back by the function io_reply).
The getopt and setopt requests is also simple to handle, we just change or read our state record:
setopts(Opts0,State) ->
Opts = proplists:unfold(
proplists:substitute_negations(
[{list,binary}],
Opts0)),
case check_valid_opts(Opts) of
true ->
case proplists:get_value(binary, Opts) of
true ->
{ok,ok,State#state{mode=binary}};
false ->
{ok,ok,State#state{mode=binary}};
_ ->
{ok,ok,State}
end;
false ->
{error,{error,enotsup},State}
end.
check_valid_opts([]) ->
true;
check_valid_opts([{binary,Bool}|T]) when is_boolean(Bool) ->
check_valid_opts(T);
check_valid_opts(_) ->
false.
getopts(#state{mode=M} = S) ->
{ok,[{binary, case M of
binary ->
true;
_ ->
false
end}],S}.
As a convention, all io_servers handle both {setopts, [binary]}, {setopts, [list]} and {setopts,[{binary, bool()}]}, hence the trick with proplists:substitute_negations/2 and proplists:unfold/1. If invalid options are sent to us, we send {error,enotsup} back to the client.
The getopts request should return a list of {Option, Value} tuples, which has the twofold function of providing both the current values and the available options of this io_server. We have only one option, and hence return that.
So far our io_server has been fairly generic (except for the rewind request handled in the main loop and the creation of an ets table). Most io_servers contain code similar to what's above.
To make the example runnable, we now start implementing the actual reading and writing of the data to/from the ets-table. First the put_chars function:
put_chars(Chars, #state{table = T, position = P} = State) ->
R = P div ?CHARS_PER_REC,
C = P rem ?CHARS_PER_REC,
[ apply_update(T,U) || U <- split_data(Chars, R, C) ],
{ok, ok, State#state{position = (P + length(Chars))}}.
We already have the data as (Unicode) lists and therefore just split the list in runs of a predefined size and put each run in the table at the current position (and forward). The functions split_data/3 and apply_update/2 are implemented below.
Now we want to read data from the table. The get_until function reads data and applies the function until it says it's done. The result is sent back to the client:
get_until(Encoding, Mod, Func, As,
#state{position = P, mode = M, table = T} = State) ->
case get_loop(Mod,Func,As,T,P,[]) of
{done,Data,_,NewP} when is_binary(Data); is_list(Data) ->
if
M =:= binary ->
{ok,
unicode:characters_to_binary(Data,unicode,Encoding),
State#state{position = NewP}};
true ->
case check(Encoding,
unicode:characters_to_list(Data, unicode)) of
{error, _} = E ->
{error, E, State};
List ->
{ok, List,
State#state{position = NewP}}
end
end;
{done,Data,_,NewP} ->
{ok, Data, State#state{position = NewP}};
Error ->
{error, Error, State}
end.
get_loop(M,F,A,T,P,C) ->
{NewP,L} = get(P,T),
case catch apply(M,F,[C,L|A]) of
{done, List, Rest} ->
{done, List, [], NewP - length(Rest)};
{more, NewC} ->
get_loop(M,F,A,T,NewP,NewC);
_ ->
{error,F}
end.
Here we also handle the mode (binary or list) that can be set by the setopts request. By default, all OTP io_servers send data back to the client as lists, but switching mode to binary might increase efficiency if the server handles it in an appropriate way. The implementation of get_until is hard to get efficient as the supplied function is defined to take lists as arguments, but get_chars and get_line can be optimized for binary mode. This example does not optimize anything however. It is important though that the returned data is of the right type depending on the options set, so we convert the lists to binaries in the correct encoding if possible before returning. The function supplied in the get_until request may, as it's final result return anything, so only functions actually returning lists can get them converted to binaries. If the request contained the encoding tag unicode, the lists can contain all unicode codepoints and the binaries should be in UTF-8, if the encoding tag was latin1, the client should only get characters in the range 0..255. The function check/2 takes care of not returning arbitrary unicode codepoints in lists if the encoding was given as latin1. If the function did not return a list, the check cannot be performed and the result will be that of the supplied function untouched.
Now we are more or less done. We implement the utility functions below to actually manipulate the table:
check(unicode, List) ->
List;
check(latin1, List) ->
try
[ throw(not_unicode) || X <- List,
X > 255 ],
List
catch
throw:_ ->
{error,{cannot_convert, unicode, latin1}}
end.
The function check takes care of providing an error tuple if unicode codepoints above 255 is to be returned if the client requested latin1.
The two functions until_newline/3 and until_enough/3 are helpers used together with the get_until function to implement get_chars and get_line (inefficiently):
until_newline([],eof,_MyStopCharacter) ->
{done,eof,[]};
until_newline(ThisFar,eof,_MyStopCharacter) ->
{done,ThisFar,[]};
until_newline(ThisFar,CharList,MyStopCharacter) ->
case lists:splitwith(fun(X) -> X =/= MyStopCharacter end, CharList) of
{L,[]} ->
{more,ThisFar++L};
{L2,[MyStopCharacter|Rest]} ->
{done,ThisFar++L2++[MyStopCharacter],Rest}
end.
until_enough([],eof,_N) ->
{done,eof,[]};
until_enough(ThisFar,eof,_N) ->
{done,ThisFar,[]};
until_enough(ThisFar,CharList,N)
when length(ThisFar) + length(CharList) >= N ->
{Res,Rest} = my_split(N,ThisFar ++ CharList, []),
{done,Res,Rest};
until_enough(ThisFar,CharList,_N) ->
{more,ThisFar++CharList}.
As can be seen, the functions above are just the type of functions that should be provided in get_until requests.
Now we only need to read and write the table in an appropriate way to complete the server:
get(P,Tab) ->
R = P div ?CHARS_PER_REC,
C = P rem ?CHARS_PER_REC,
case ets:lookup(Tab,R) of
[] ->
{P,eof};
[{R,List}] ->
case my_split(C,List,[]) of
{_,[]} ->
{P+length(List),eof};
{_,Data} ->
{P+length(Data),Data}
end
end.
my_split(0,Left,Acc) ->
{lists:reverse(Acc),Left};
my_split(_,[],Acc) ->
{lists:reverse(Acc),[]};
my_split(N,[H|T],Acc) ->
my_split(N-1,T,[H|Acc]).
split_data([],_,_) ->
[];
split_data(Chars, Row, Col) ->
{This,Left} = my_split(?CHARS_PER_REC - Col, Chars, []),
[ {Row, Col, This} | split_data(Left, Row + 1, 0) ].
apply_update(Table, {Row, Col, List}) ->
case ets:lookup(Table,Row) of
[] ->
ets:insert(Table,{Row, lists:duplicate(Col,0) ++ List});
[{Row, OldData}] ->
{Part1,_} = my_split(Col,OldData,[]),
{_,Part2} = my_split(Col+length(List),OldData,[]),
ets:insert(Table,{Row, Part1 ++ List ++ Part2})
end.
The table is read or written in chunks of ?CHARS_PER_REC, overwriting when necessary. The implementation is obviously not efficient, it is just working.
This concludes the example. It is fully runnable and you can read or write to the io_server by using i.e. the io_module or even the file module. It's as simple as that to implement a fully fledged io_server in Erlang.