TCP library

[Martin Wierich]

Hi there,

I wrote:

>1.  I vote for an extension of the StdFile module to deal with network
>connections (TCP and (later) pipes). In many cases blocking does not
>matter, and with Concurrent Clean (not Clean) this doesn't matter anyway.
>2.  There is also a need for the mentioned send/receive functions, so that
>one can nicely specify sequentialisation. These functions have another
>signature than the fread/fwrite functions. The send/receive functions could
>probably operate on the same set of objects than the fread/fwrite functions
>(including "ordinary" files and stdio)

... not to mention pipes and TCP connections.

Later "Richard A. O'Keefe" wrote about me:

>There is a sense in which he is obviously right about the distinction
>between "File" and "Network" IO.  However, there is also an important
>sense in which he is as obviously wrong, and I tried to explai that
>in my previous message.  He is right that passive local data containers
>"file" *may* behave differently from communications endpoints "network".
>The point that I was trying to make, and which I believe we are agreed
>on is that
>
>    Almost[%] all of the operating systems where Clean is used
>    allow at least one kind of communications endpoint to
>    masquerade as and be accessed as a plain file.
>        [%: I listed UNIX, OS/2, and Windows.  I am not sure about MacOS.]
>
>Worse still,
>    All the operating systems where Clean is used allow remote file
>    systems to be accessed *through* a network *as if* they were
>    local, and thus plain file access to something which *is* a plain
>    file may incur arbitrary network delays.

I am not wrong. This is one of the most weird communications I ever had to take
part. First, Richard makes a proposal, and then I say: "Good idea ! I agree"
(see above). Afterwards he accuses me for being wrong. How should I interprete:

>The point that I was trying to make, and which I believe we are agreed
>on is that

So we agreed upon the fact, that the Clean programmer should be able to do a
bytestream oriented IO which abstracts from the "implementation" (be the
bytestream a file, a unix pipe or a TCP connection), but on the other hand this
opinion is wrong ? If I would have made a wrong statement somewhere, then
Richard should cite me, but he can't.

>Martin Wierich's point about two-way communication is a valid
>observation about the trickiness of trying to co-ordinate two separate
>end-points in a lazy language; a compelling argument using for a *single*
>bidirectional channel with 'receive' rightly seen as a mutating operator,
>rather than having separate endpoints.

There's no problem. The distinction between a receive channel and a send channel
for one TCP connection is the most general approach, and we need it to be like
that. We can easily put these two types into one record, instanciate the Send
and Receive classes with such a record, and then we have a single bidirectional
channel type for one connection. The implementation is almost trivial. We are
actually considering to offer this channel type as a part of the Object IO
library.

>1.  Even when you _think_ you are dealing with plain files, you really
>    do want to have timeout available (I've had a UNIX box stall for
>    10 minutes trying to search a remote directory).

Yes. Good point. As I said, the functions offered in StdFile are not sufficient.

>2.  Just because you open it like a file doesn't mean that read
>    really _is_ a pure operation; {UNIX,OS/2,Windows} named pipes live
>    in the file space and may be treated like files *but* reading from
>    them changes them just like truncating a file, so a Clean program
>    should not be allowed to open a pipe for shared input.  Even
>    without networks, think of reading from /dev/tty in UNIX or COM1:
>    in DOS or .BIn in MacOS.

Another good point.

>3.  But a program should be allowed to find out what it will be allowed
>    to do, so Clean programs need a way to _tell_ whether a name in the
>    file system name space stands for a data container or a communcations
>    end point (such as a named pipe, socket, or serial port).

A third good point. (BTW, these good points are not contradictory to my
statements.)

>4.  Interacting with another program (whether remotely through a
>    network or locally through message queues or whatever) requires
>    destructive reads and writes to be synchronised, and that appears
>    to be easiest when a _single_ Clean value is used for both
>    directions of communication.

See above.

>5.  Some remote programs use Java protocols, some remote programs
>    use Erlang protocols, some remote programes use CORBA protocols,
>    some will use Clean protocols, but some use text.  The transitions
>        Clean program writes file, file read by GNU plot
>    =>  Clean program writes to named pipe read by co-running local GNU plot
>    =>  Clean program writes to socket read by co-running remote GNU plot
>    should be reasonably simple and really _should_ not involve changing
>    most of the code of the Clean program.

Maybe Richard misunderstood, that assigning different types to different kinds
of  IO channels (files,pipes,TCP connections,...) means, that it's impossible to
use the same functions to deal with these objects. But we have OVERLOADING. So
here is my example of a Clean function, that writes a gnuplot command into
"something" that can be a "ordinary" file, a pipe or a TCP channel. (I hope I
remember gnuplot's syntax right):

plot :: *(*stream ByteSeq) *World -> (*(*stream ByteSeq),*World)  | Send stream
plot byteStream world
    = send byteStream (toByteSeq "plot [0:10] sin(x)\n") world

This function can be called with any of the stated objects.

bye
  Martin Wierich