class telnet_session :object..end
 The telnet_session object has two queues, one for arriving data,
 one for data to send.
 Once the session object is attached to an event system, it connects
 to the remote peer, and processes the queues. Input is appended to
 the input queue; output found on the output queue is sent to the
 other side.
 If input arrives, a callback function is invoked.
 You may close the output side of the socket by putting Telnet_eof
 onto the output queue.
 Once the EOF marker has been received, a Telnet_eof is appended to
 the input queue, and the connection is closed (completely). The
 session object detaches from the event system automatically in this
 case.
Hints
Set an input handler as callback function in the session object. The input handler is called when new input data have been arrived. It should inspect the input queue, process the queue as much as possible, and it should remove the processed items from the queue. While processing, it may add new items to the output queue.
 If you are not within the callback function and add items to the
 output queue, the session object will not detect that there are
 new items to send - unless you invoke the update method.
 If you want option negotiation, it is the simplest way to use
 the special option negotiation methods. Configure the options
 as you want (invoking enable, disable etc), but do not forget
 to modify the way input is processed. Every Telnet_will, _wont,
 _do, and _dont command must be passed to process_option_command.
method set_connection : telnet_connector -> unitmethod set_event_system : Unixqueue.event_system -> unitmethod set_callback : (bool -> unit) -> unit
 Note Synch: If the client sees a data mark command it will assume
 that it is actually a Synch sequence. The client automatically
 discards any Telnet_data commands from the input queue (but not
 Telnet_datas inside subnegotiations). The data mark command
 itself remains on the queue.
method set_exception_handler : (exn -> unit) -> unitUnixqueue.run); see the documention
 there.
 If you do not set the exception handler, a default handler is
 active. It first resets the session (see method reset), and
 then wraps the exception into the Telnet_protocol exception,
 and raises this exception again.
method output_queue : telnet_command Queue.tupdate
 method which indicates to the event system that new data to
 send is available.
 After commands have been sent, they are removed from the queue.method input_queue : telnet_command Queue.tmethod get_options : telnet_optionsmethod set_options : telnet_options -> unitmethod reset : unit -> unitThe following methods deal with Telnet protocol options. These are negotiated between local and remote side by the Will, Won't, Do and Don't commands.
 The "local" options describe the modification of the behaviour
 of the local side; the "remote" options describe the modifications
 of the remote side. Both set of options are independent.
 This object may track the set of accepted and rejected options
 if the following methods are used; but this works only if
 the Telnet_will, _wont, _do, and _dont commands received from
 the remote side are processed by process_option_command. So
 you need to invoke this method for the mentioned commands in
 your command interpretation loop.
The idea is: If you enable an option, it is possible to switch it on. If the remote side requests the option to be enabled, the request will be acknowledged. If the remote side does not request the option, it remains off.
 You can also actively demand an option (offer_local_option,
 request_remote_option); this is of course only possible if
 the option is already enabled. In this case the client tries
 actively to switch it on.
You can also disable an option. If the option is on, the client actively rejects the option; following the Telnet protocol this is always possible (rejections cannot be rejected).
 The reset methods are somewhat dangerous. They simply reset
 the internal state of the client, but do not negotiate. This
 possibility was added to allow the Timing Mark option to send
 again timing marks even if the previous timing marks have
 already been accepted. After reset, the client thinks the
 option was never negotiated; but nothing is done to tell
 the remote side about this.
 option_negotiation_is_over: true if no option negotiation is
 pending (i.e. nothing has still to be acknowledged).
method enable_local_option : telnet_negotiated_option -> unitmethod enable_remote_option : telnet_negotiated_option -> unitmethod disable_local_option : telnet_negotiated_option -> unitmethod disable_remote_option : telnet_negotiated_option -> unitmethod offer_local_option : telnet_negotiated_option -> unitmethod request_remote_option : telnet_negotiated_option -> unitmethod reset_local_option : telnet_negotiated_option -> unitmethod reset_remote_option : telnet_negotiated_option -> unitmethod get_local_option : telnet_negotiated_option -> telnet_option_statemethod get_remote_option : telnet_negotiated_option -> telnet_option_statemethod option_negotiation_is_over : boolmethod process_option_command : telnet_command -> unitmethod fetch_subnegotiation : string optionTelnet_sb at the beginning of the input queue,
 remove this command Queue.take, and invoke fetch_subnegotiation.
 This method scans the queue and looks for the associated 
 Telnet_se command. If it does not find it, None is returned.
 If Telnet_se is found, the parameter enclosed by the two commands
 is returned as Some s where s is the parameter string. Furthermore,
 in the latter case the data items and the closing Telnet_se are
 removed from the queue.method attach : unit -> unitmethod run : unit -> unitmethod update : unit -> unitmethod send_synch : telnet_command list -> unit
 Sending a Synch sequence has higher priority than the output
 queue; processing of the output queue is deferred until the
 Synch sequence has been completely sent.
method expect_input : bool -> unittrue by default.