Newsgroups: comp.sys.transputer
From: robbel@fwi.uva.nl (Robert Belleman)
Subject: Re: OCCAM: Best way to multiplex protocols over one link?
Organization: FWI, University of Amsterdam
Date: 2 May 1994 11:13:47 GMT
Message-ID: <2q2n9b$bg7@mail.fwi.uva.nl>


My problem is not the avoidance of deadlocks (not in the first place),
rather how to efficiently relay different channel protocols over one
link. As an example, consider the following protocol:

    PROTOCOL PACKET
      CASE
        file;       INT::[]BYTE           -- note: counted array
        mats;       INT::[][2][2]REAL32   -- note: counted array
        box;        [64][64][64]INT16     -- static, BIG array (512k)
        status;     INT
        start;      BOOL
    :

Ideally, a multiplexor should be able to route these two protocols
over an interprocessor protocol, say

    PROTOCOL interprocessor INT::[]INT :  -- or maybe even ANY

irrespective of the amount of data that is transmitted, especially in
the counted array cases.

If I would assume that no messages exceed a certain size, I could
either allocate an extremely large buffer (more even, to avoid
deadlock), or breakup the datastructures (RETYPE) in equally sized
blocks. The first solution is inefficient as most of the time the
buffer will be poorly used AND if for some reason some message is
bigger than expected the process will be invalid; the second
solution makes code extremely unreadable, inflexible and not portable.

I had hoped to get away with a process like this:

    PROC mux([]CHAN OF PACKET from.process, to.process,
             CHAN OF ANY out, in)

      PAR
        -- First part: receive packets from processes and send them over
        -- to the other side;
        --
        [BUFSIZE]BYTE buffer:
        []CHAN OF ANY from.proc RETYPES from.process :
        WHILE TRUE
          ALT id=0 FOR (SIZE from.proc) -- for each channel from a process
            from.proc[id] ? buffer      -- get packet from this process
              out ! id; buffer          -- send process id and buffer

        -- Second part: receive packets from other side and send them over
        -- to the respective process;
        --
        [BUFSIZE]BYTE buffer:
        []CHAN OF ANY to.proc   RETYPES to.process :
        INT id :
        WHILE TRUE
          SEQ
            in ? id; buffer             -- get process id and buffer
            to.proc[id] ! buffer        -- send packet to respective process
    :

The idea is to just 'blindly' read all bytes from the channel from one
side, copy them over to the other processor, and then 'blindly' send
the exact sequence back to the receiving process, thereby still adhering
to the channel protocol. Result: this only works when 'buffer' is large
enough. Anything more will make the process invalid. Also; there is no
way to find out how many bytes were transferred when communication ends.
A packet could be partially received. This is especially a problem with
variant protocol packets as the tags will occupy only one byte, but the
mux process has no knowledge on wether a tag is received or a bigger
message (nor should it).

I had hoped that by changing the channel input to 'from.proc[id] ?
[buffer FROM 0 FOR BUFSIZE]' I could persuade the processor to cease
input after BUFSIZE bytes were read, but that turns out to be a no-go.

So, in return to some of your answers; I still have some questions. :-)

Is the Inmos Virtual Channel Software capable of handling variable
sized messages efficiently or do I still have to allocate a large
enough buffer for it?
Is Southampton's Univ. 'vcr' package worth looking into with this
respect?

By the way; Xinan Tang, you have seen the code I tried, I would be
interested in seeing yours!

Thanks for you help this far!

-- Rob

-- 
[] Robert Belleman              robbel@fwi.uva.nl     "If life is a stage,  []
[] Dept. of Computer Systems    robbel@nki.nl          I want some better   []
[] University of Amsterdam                             lighting."           []
[] the Netherlands.                                                         []

