ocamlnet-devel — Developer discussion

Re: [Ocamlnet-devel] Thoughts on addresses

[Gerd S. <in...@ge...>]

On Sun, 07 Oct 2001, Patrick M Doane wrote:
>I've been working on e-mail address support today and have a couple
>of suggestions:
>
>  - I think it may be good to factor out the address support to
>    a Netaddress module.  It seems to distract from the focus of the
>    Netmessage module.

Agreed. This is another fundamental structure like Netdate.

>  - Object-based representations for addresses may not be the best idea.
>    I forgot that they don't support equality, which makes it impossible
>    to use them as keys and it also complicates testing. 

You can use objects as keys. The object ID is used in this case. I.e.
obj1 = obj2 <=> obj1 and obj2 are the same object. Of course, objects are not
compared component by component.

I think the comparison by components does not make sense because there is no
way to find out whether two mailbox references mean the same mailbox or not.
Maybe the object ID is better. But I am undecided.

Testing: It is possible to define printers for objects.

>I would 
>    recommend switching back to a record based structure:
>
>      type mailbox = {
>        name:  string option;
>        route: string list;
>        spec:  addr_spec;
>      }

Better: mb_name, mb_route, mb_spec. This avoids name clashes.

>      type t =
>        [ `Mailbox of mailbox
>        | `Group of string * mailbox list
>        ]
>
>Patrick

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   ge...@ge...
Germany                     
----------------------------------------------------------------------------

Re: [Ocamlnet-devel] Design issues for protocol support

[Gerd S. <in...@ge...>]

On Sat, 06 Oct 2001, Patrick M Doane wrote:
>On Fri, 5 Oct 2001, Gerd Stolpmann wrote:
>
>> I think retr and top should return in_obj_channel (the user's perspective).
>
>Yes of course, I'm not sure what I was thinking.
>
>> I implemented pipelining for my HTTP client. It is very complicated and
>> error-prone.
>
>Much of the day-to-day work that I do involves a transaction based
>protocol that supports pipelining.  It is definitely very error-prone,
>although this is mostly from the perspective of the client and the server
>specific code. I would imagine that some message queues and callback
>tables should be sufficient inside the protocol module to "support"
>pipelining. 
>
>What's the minimum that we can reasonably get away with?

The HTTP client has two message queues, one for input, and one for output. Most
of the time this design is very simple, but it becomes complicated when errors
happen. For example, if there is an unexpected EOF, the queues must be
resynchronized (the output queue is ahead, and some HTTP requests may be lost).

>> >Another fundamental issue to explore is event-based vs thread-based
>> >systems.  The POP module included here would only work well in a
>> >thread-based application.
>> 
>> Looking back, it was a good choice to implement the HTTP client
>> event-driven.  The reading and writing parts of the client can interact
>> without synchronization problems, and can react on abnormal situations.
>> If the client had been implemented with threads (i.e. one thread for
>> reading and another thread for writing), a lot of condition variables
>> would have been necessary to synchronize them. (Or better: In the
>> current code these variables exist, too, but they are plain variables
>> that need not to be protected by mutexes.) 
>
>This is good information to know about. How would you think about
>modifying the POP interface such that it could work well in an event
>driven world?

A very simple event-driven interface is that for my telnet module. I think
the POP interface could be very similar:

type telnet_command =
    Telnet_data of string
  | Telnet_nop
  | Telnet_dm           (* data mark *)
  | Telnet_brk          (* break *)
  | Telnet_ip           (* interrupt process *)
  | ... (* much more *)

Telnet commands can be sent in both directions. For POP, you should consider
two command sets for input and for output.

type telnet_connector =
    Telnet_connect of (string * int)
  | Telnet_socket of Unix.file_descr

The connector specifies the server to contact.

class telnet_session :
  object
    method set_connection : telnet_connector -> unit
        (* Sets the host name and the port of the remote server to contact. *)

    method set_event_system : Unixqueue.event_system -> unit
        (* Sets the event system to use. By default, a private event system
         * is used.
         *)

    method set_callback : (bool -> unit) -> unit
        (* Sets the callback function. This function is called after new
         * commands have been put onto the input queue. 
         * The argument passed to the callback function indicates whether
         * a 'Synch' sequence was received from the remote side or not.
         * [... details about Synch left out ...]
         *)

    method set_exception_handler : (exn -> unit) -> unit
        (* Sets the exception handler. Every known error condition is
         * caught and passed to the exception handler. [...]
         * 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.t
        (* The queue of commands to send to the remote side. If you add new
         * commands to this queue, do not forget to invoke the 'update'
         * 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.t
        (* The queue of commands received from the remote side. This class
         * only adds commands to the queue (and invokes the callback 
         * function). The user of this class is responsible for removing
         * commands from the queue which have been processed.
         *)

    ...
    (* A number of methods dealing with option negotiation *)

    method attach : unit -> unit
        (* Attach to the event system. After being attached, the client
         * is ready to work.
         *)

    method run : unit -> unit
        (* Run the event system *)

    method update : unit -> unit
        (* If there are commands in the output queue, the event system is
         * signaled that this client wants to do network I/O.
         *)

    method send_synch : telnet_command list -> unit
        (* At the next output oppurtunity, a Synch sequence is sent to
         * the remote peer. This means that the passed commands, extended
         * by an additional Data Mark command, are sent to the peer as
         * urgent data.
         * 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.
         *)
  end

The telnet session object receives a byte stream and converts it into a queue of
input commands, and it can encode the queue of output commands as bytes. It
is simple to use: If input has arrived, the callback function is invoked and
one can fetch the next command from the input queue. If output is to be sent,
one can add it to the output queue, and call the update method to signal that
there is new material on the output queue to process.

You may consider to base POP on this Telnet module. Of course, you also want a
higher-level module that queues POP jobs instead of simple commands. The design
could be similar, but instead of a sum type like telnet_command I would use 
objects (because the objects could track which parts of the jobs are already
done and which not).

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   ge...@ge...
Germany                     
----------------------------------------------------------------------------

[Ocamlnet-devel] Interpretation of 2 and 3 digit years

[Patrick M D. <pa...@wa...>]

One of the modifications in RFC 2822 (Internet Message Format) is explicit
instructions on the interpretation of two or three year date formats:

   Where a two or three digit year occurs in a date, the year is to be
   interpreted as follows: If a two digit year is encountered whose
   value is between 00 and 49, the year is interpreted by adding 2000,
   ending up with a value between 2000 and 2049.  If a two digit year is
   encountered with a value between 50 and 99, or any three digit year
   is encountered, the year is interpreted by adding 1900.

The Netdate code implements a slightly different heuristic:

  if y >= 100 then     y
  else if y < 69 then (2000 + y)
  else                (1900 + y)

which is basically the same as C version that this code is based on.

I'm in favor of the rules described in RFC 2822 although I would have
limited the adjustment to a tighter bound (like 150 instead of 999).

Is anyone aware of other intrepretations that we might need to follow? If
not, it is probably best to adopt the RFC 2822 semantics.

Patrick

[Ocamlnet-devel] Thoughts on addresses

[Patrick M D. <pa...@wa...>]

I've been working on e-mail address support today and have a couple
of suggestions:

  - I think it may be good to factor out the address support to
    a Netaddress module.  It seems to distract from the focus of the
    Netmessage module.

  - Object-based representations for addresses may not be the best idea.
    I forgot that they don't support equality, which makes it impossible
    to use them as keys and it also complicates testing. I would 
    recommend switching back to a record based structure:

      type mailbox = {
        name:  string option;
        route: string list;
        spec:  addr_spec;
      }

      type t =
        [ `Mailbox of mailbox
        | `Group of string * mailbox list
        ]

Patrick