Page Bottom  References from Other Sources


I felt I was a little brief in our conversation yesterday, so I thought I'd give you a little more background on network "sockets" for your project brain to chew on for a while. The reason I even mentioned them has a lot to do with the "using the right tool for the job" kind of concept, which I think you're much in favor of. Thus, if you need to provide web pages then use a web server, but if you only need a centralized process/repository for an application, then skip the web and just build it that way.

Ok, "sockets" is a concept that came out of Berkeley in the 70's and since then everyone has used them in every machine/network on the planet. It's a conceptualized way of looking at program-to-program communications in general, and it works very well. Sockets are implemented in APL using []NI (you may have heard of this ), and it's usability is such that normally there isn't any point in writing cover functions for it for general use (only for specific applications, such as web browsing or FTP transfers or one of the hundreds of other things you do with networks).

The basic concept is that you build a "pipe" between two computers, send data through that pipe, and tear it down when you're done. The data being transferred is just a long vector of arbitrary bytes (with no particular start/end points), but most people just use it to send plain text (which transfers well between dissimilar systems). Our []NI implementation allows that, of course, and will also send pure numeric-format bytes if necessary, but also allows us to send whole APL variables (even nested ones) across as well (as long as we have the same kind of APL system on the other side turning them back into variables). This makes writing cooperating APL-to-APL applications very easy.

Without going into too much detail on the actual mechanics of it all, I thought I'd briefly touch on two general mechanisms it encompasses. You've heard that the networks are generally based on TCP/IP, right? Well, that's actually two different "protocols": "TCP" and "IP". IP is the low-level protocol and works like a postcard. You send off a message and hope it gets to the right destination eventually. This is also called a "connectionless" protocol. TCP is the higher-level protocol and uses IP internally. TCP is a "connection-based" protocol and works more like a telephone call, in that it sets up a constant link (pipeline) between two computers and manages it for you while both ends send multiple messages (data packets) back and forth between them. TCP provides (1) verification the the receiving computer is present, (2) notification of connection loss, (3) guaranteed message delivery, and (4) guaranteed ordering of data packets, none of which is provided by IP itself. TCP is normally what you want to use for applications. []NI supports both protocols. There are no practical limits to how many TCP pipes or IP messages go flying around between programs & computers at one time, so you can set up multiple pipelines (to the same place or to different places) in any given program for your application needs.

Now, knowing all that, maybe you can dream up some inventive ways to do your favorite projects without being constrained by other people's notions of what the "web" is.

Davin Church, 6/29/02

horizontal line
to home page e-mail Page Top