Networking HC
| Volume Number: | | 5
|
| Issue Number: | | 12
|
| Column Tag: | | HyperChat™
|
Related Info: AppleTalk Mgr
A Look Into Networking 
By Donald Koscheka, Ernst & Young, MacTutor Contributing Editor
Note: Source code files accompanying article are located on MacTech CD-ROM or source code disks.
Programming the Network
Network programming is fun. Over the past year, I’ve presented a suite of XCMDs that provide the Hypercard developer with network access. Rather than present a new XCMD this month, I thought it might be interesting to revisit some of the xcmds that we developed during the year. If you don’t have access to back issues of Mactutor, you can obtain the source code for these xcmds from this magazine.
Programming the network is not unlike programming in Hypertalk. In both instances, you are concerned with the behavior of distributed processes. In HyperTalk, processes are distributed over several card and background objects. On the network, objects are distributed over time.
Time distribution of processes adds a new wrinkle to the programming task: how do you know when a given process has completed? The problem stems from the fact that we operate the network asynchronously; when we issue a request for some network service, we don’t wait around for an answer. Rather, we return to Hypercard, leaving the network to handle the request in its own good time.
Figure 1 depicts a card for a prototypical network application called Hyperserver. The card contains two icons, each of which provides some access to the network. Clicking on the volumes icon will cause the card to display a list of available servers. Selecting one of these servers will immediately send a message to the selected server requesting a list of its mounted volumes. Similarly, the catalog icon will return a catalog of the current folder on the server (for now, I leave it to your imagination to determine what other things one can do with such a card).
Figure 1. A prototypical screen for HyperServer
The process of sending a message to a server requires that you first call the call the server. Next you send a “get volumes” message to the server. Then you must wait for a response from the server. Once the server responds, you hangup).
Waiting for some input before advancing to the next stage suggests a state machine. Figure 2 depicts just such a state machine. Each circle in the diagram is a state. The double circles are termini. They start or begin a process. The arrows are state transitions, their labels tell us what stimulus will force a transition to the next state. The looping arrows in the diagram suggest the concept of waiting. For example, when a call request is made, you can’t immediately start talking, you have to wait for the other party to answer first. The process of answering the call triggers a transition to the connected state. Once connected, requests can be made to the server. Since requests imply a response, this state needs to wait for input before moving on. The process of receiving an answer to the request will trigger a transition to the next state (handle response). Once the request is serviced, we can go back to the connected state where we either wait for input and send another request (or hang up if that’s appropriate).
State transitions can occur in response to one of two classes of stimuli: external or internal. External stimuli comprise information coming in over the “wire”. Examples of external stimuli include service requests to a server and responses coming from a server. In figure 2, we model the external stimuli as the Service state and the Handle State. The handle state accepts the input from the remote end as a response to some previous request issued in the send state. For this reason, you should never get to the handle state unless you first pass through the send state.
The respond state in Figure 2 can only be reached from the service state. That is, you can only respond to a stimuli given that a request for service was made from a remote end. (For readability, not all states are depicted in the figure).
Figure 2 The State Machine For HyperServer
Internal stimuli are called requests. Requests are messages that are sent to a server. Once a request is issued, we must wait for a response. For example, calling is an example of a message that request a connection with the server.
Once the server answers the call, we can move to the connect state. The connect state is implemented in the idle method of the stack method in listing 1. In addition to listening for external stimuli via ADSPListen, the idle method also manages the request mechanism.
We synchronize requests using a simple queue. Requests get added to the end of the queue and get serviced from the start of the queue. The queue is stored in the global container “message_queue”. Each line in message_queue corresponds to a message. The first line in message_queue is the next message to service (not the current message). To execute a message, we first move it into the “message_pending” container. Every other element in the queue then moves up in the line.
The message_pending item will be executed on the next activation of the idle method. If a message is sent that requires some external response, it should be followed by a “PENDING” message. Pending does nothing which is why it’s useful as a blocking mechanism. The only way for the queue to advance is to have some method activate the NextMessage method. So PENDING will remain the current message in the queue until some external stimulus unblocks it.
For example, to issue a call to a remote called “Allen” you might execute something to the effect of:
AddMessage “Call”"e&”Allen”"e
AddMessage “PENDING”
On the next pass through the idle method, the Call message will be executed invoking the call method in the script. The call method dials up the remote end and activates nextMessage which advance the queue to the next message, in this case the current message becomes “PENDING”.
The queue cannot be unblocked until the server answers the call or the call times out. When the call is answered (in ADSPListen), the connectionMade method is activated unblocking the “PENDING” message.
Some messages have don’t care results. When we hangup on a remote end, we generally don’t care to wait around to see if the other guy hung up. Thus the HangUp message is not followed by a pending message.
As a rule, if you have a message that issues a request, you must follow the message with a “PENDING” message will tells the state machine to wait for an external stimulus before proceeding.
Listing 1 is the stack script that implements this state machine plus the response handlers (not shown in Fig. 1). Before running the state machine, we install HyperADSP in the openstack method. Similarly, we shut down HyperADSP in the closestack method.
Think of the idle method as implementing the connect state and the rest of the script should be a little easier to read. For brevity, I’ve left out the methods that originate the requests, but they’re easy enough to reconstruct (or get a copy of this month’s disk for a demo).
-----------------------------------------------
-- Following are the stack methods for opening
-- closing and listening for traffic on the
-- network
--
-- Due to space limitations, this stack is not
-- complete. This month’s source disk contains
-- a complete demo of this stack.
-----------------------------------------------
on openstack
global globalADSPData, globalSKTData, globalNBPData, myEntityName
global HyperADSPData, adspcaller, LookupTable
global message_queue, message_pending
set the cursor to 4
put empty into card field “current Server”
put empty into card field “Subscribers”
put empty into card field “Current Pathname”
put empty into card field “Current Catalog”
put empty into card field “log”
put empty into message_pending
put empty into message_queue
if globaladspdata is empty then
set the cursor to arrow
adspinstall
if the result is not empty then
put the result
else
nbpOpen
if the result is not empty then
answer the result with “OK”
else
nbpRegisterName “”, “HyperServer”
log “Welcome to HyperADSP!”
end if
end if
else
log “HyperADSP already open!”
end if
end openstack
on idle
global message_pending
--
-- if no message is pending, get one from the queue
-- if the queue is empty, do nothing
--
if message_pending is empty then NextMessage
if message_pending is not empty then
send message_pending
end if
adspListen “getTheMessage”
pass idle
end idle
on getTheMessage
global hyperadspdata, adspcaller, message_pending, incoming
set cursor to 4
set lockscreen to true
put hyperadspdata into incoming
get line 1 of incoming
--
-- Notice how we “turn the messages around” here.
-- a put message tells us to take the incoming data
-- a get message tells us to handle an incoming request
if word 1 of it is “put” then Receive incoming
if word 1 of it is “get” then Handle incoming
set lockscreen to false
set cursor to arrow
end gettheMessage
on closeStack
adspRemove
if the result is not empty then
answer the result with “OK”
else
nbpClose
end if
end closestack
----------------------------------------------
-- Network Callback methods.
--
-- These methods are executed in response to
-- some activity on the network
--
-- connectionMade : answer an incoming call
-- doALookup: Update the names table
----------------------------------------------
on connectionMade
global adspcaller
if adspcaller is not empty then
-- now that the connection is made, we can dismiss the calling
-- message from the queue:
Log “Connect to:”&&adspcaller
put empty into adspcaller
NextMessage
end if
end connectionMade
on DoALookup
-----------------------------------------------
--
-- DoALookup returns a list of names along with
-- their registered types. There is a catch
-- that we need to handle: If we want to display
--the name without the type, we need to delete
-- the last item in the line.
--
-- For example:
-- Koscheka, Don, HyperServer
-- needs to be reported as:
-- Koscheka, Don.
--
-- Note that asking for item1 of the line won’t
-- do since the comma is part of the registered
-- name.
--
-----------------------------------------------
global lookupTable, currentZone
set the cursor to 4
put GetZoneInfo( TRUE ) into currentZone
put nbplookupnames( “HyperServer”, currentZone ) into lookupTable
repeat with i = 1 to the number of lines in lookupTable
get the number of items in line i of lookupTable
put empty into item it of line i of lookupTable
get the number of characters in line i of lookupTable
if character it of line i of lookupTable is “,” then
put empty into character it of line i of lookupTable
end if
put line i of lookupTable into line i of card field “subscribers”
end repeat
set the cursor to arrow
End DoALookUp
----------------------------------------------
-- Generic utilities
--
-- SelectLine : return the content of the line
-- clicked in by the user (card field only)
--
-- isBlank: return true if the field is empty
-- or contains just white space.
----------------------------------------------
on log mess
-- the idea for a network log is borrowed
-- from Chris Allen.
repeat while the number of chars of cd fld “Log” > 15000
delete line 1 of cd fld “Log”
end repeat
put “•”&&mess&return after cd fld “log”
end log
Function SelectLine theField
--
-- select a line from the given card field
-- Accepts the short name of a card field as input
--
put empty into my_answer
--
-- When selecting a line from a field,
-- you need to take into account that the
-- field may have been scrolled.
--
-- To determine the number of scrolled lines
-- divide the number of scrolled pixels by the
-- number of pixels per line
--
put the scroll of card field theField into box_top
put the textheight of card field theField into tsize
put round( box_top/tsize ) into lineNum
--
-- You get a mouseup in global coordinates
-- To find the line hit, you need to convert
-- to local coordinates.
--
put item 2 of the rect of card field theField into x_global_offset
put item 2 of the clickloc into x_hit
-- Once you find the mousehit point,
-- convert it to a line relative to top of box.
-- This “relative line” is added to the number
-- of scrolled lines to determine the actual
-- line number (e.g. if 10 lines have been scrolled
-- then the first line in the field is 11, not 1).
--
subtract x_global_offset from x_hit
add trunc( x_hit/tsize) to lineNum
--
-- in the arithmetic, line numbers will be
-- normalized to 0 rather than 1. Hypercard
-- starts at line 1 so adjust the offset.
--
add 1 to lineNum
put line lineNum of card field theField into my_answer
return my_answer
end SelectLine
function is_blank string
get character 1 of string
if it is space or it is empty or it is tab or it is return then
return true
else
return false
end if
end is_blank
----------------------------------------------
-- Queue Management
--
-- These routines handle management of the message
-- queue. Excuse the logic; if Hypercard has an
-- Achille’s heel, it’s the lack of useful data
-- structures.
--
-- Addmessage : add a message to end of queue
-- RemoveMessage: remove a message from the queue
----------------------------------------------
on AddMessage the_memo
global message_queue
get the number of lines in message_queue
put the_memo into line it+1 of message_queue
end addMessage
on NextMessage
--
-- removing a message implies that the removed
-- message get put into the message_pending container
-- This method should only be called once the pending
-- message has been serviced
--
global message_queue, message_pending
if message_pending is not empty then log message_pending
put line 1 of message_queue into message_pending
delete line 1 of message_queue
end NextMessage
-----------------------------------------------
-- Message Management
--
-- These routines handle management of the possible
-- messages that can be received by the network.
-- all messages have the form:
--
-- Line 1: Message Type (token)
-- Line 2: Message Sender (string)
-- Line 3..n: Message dependent data
--
-----------------------------------------------
Function BuildHeader mess, name
put mess into line 1 of temp
put name into line 2 of temp
return temp
end BuildHeader
on call someone
adspCall someone
NextMessage
-- notice that this message needs to be pended also
-- The block will be cleared by the connectionMade method
end call
on hangup someone
ADSPHangup someone
NextMessage
end hangup
on PENDING
-- This is a “wait for completion” message. Because
-- it does nothing, it blocks the message_queue until
-- some data is received. The receive method will clear
-- the pending message. Only the nextMessage method can
-- unblock the queue. Notice that nextMessage should get
-- called only after the expected data is returned.
end PENDING
on getcatalog server, folder
global myEntityName
--
-- Client is asking for a directory of the requested
-- folder. Service the request...
--
if server is not empty then
put BuildHeader( “get catalog”, myentityname) into send_this_message
put folder into line 3 of send_this_message
ADSPTalk server, send_this_message
end if
NextMessage
end getcatalog
on getVolumeList server
global myEntityName
if server is not empty then
put BuildHeader(“get volumes”, myEntityName ) into send_this_message
Log server
log send_this_message
adsptalk server, send_this_message
end if
NextMessage
end getvolumeList
----------------------------------------------
--
-- Message request methods. Requests are assembled
-- by these methods and added to the request queue
--
----------------------------------------------
on request_volumes
global message_queue
put selectline( the short name of the target ) into theServer
if theServer is not empty then
put theServer into card field “current server”
AddMessage “Call”&"e&theserver"e
AddMessage “Pending”
AddMessage “getVolumelist”&"e&theserver"e
AddMessage “Pending”
AddMessage “Hangup”&"e&theserver"e
end if
end request_volumes
on request_catalog
global message_queue
put card field “current server” into theServer
if theServer is not empty then
AddMessage “Call”&"e&theserver"e
AddMessage “Pending”
put quote&cd fld “current pathname”"e into temp
AddMessage “getcatalog”&"e&theserver"e&”,”&temp
AddMessage “Pending”
AddMessage “Hangup”&"e&theserver"e
end if
end request_catalog
-----------------------------------------------
-- Message response methods. These methods will
-- respond to a particular message from a remote
-- end in whatever manner is appropriate. Note
-- that responses don’t get queued, they go
-- right out on the line.
--
-- Response messages take the same form as request
-- messages. Notice that the response methods
-- use myentityname to tell the client which server
-- is providing the response.
-----------------------------------------------
on Receive something
--
-- A request that was made in the past is
-- being addressed, do something with the
-- incoming data (for now, just display it)”
--
if “volume” is in line 1 of something then
log something
end if
if “catalog” is in line 1 of something then
delete line 1 of something
put line 1 of something into cd fld “current server”
delete line 1 of something
put something into cd fld “current catalog”
end if
NextMessage
end receive something
on Handle request
--
-- incoming caller is making a request, do
-- something about it
--
get word 2 of line 1 of request
put line 2 of request into to_client
if “catalog” is in it then
put line 3 of request into of_folder
return_catalog of_folder, to_client
end if
if “volumes” is in it then
return_volume_list to_client
end if
end handle
on return_catalog folder, client
global myEntityName
if client is not empty then
put BuildHeader( “put catalog”, myEntityName ) into the_response
Put GetCatalog( “”, directoryID ) into temp
put the_response&return&temp into the_response
ADSPTalk client, the_response
end if
end return_catalog
on return_volume_list client
global myentityname
if client is not empty then
put BuildHeader( “put volumes”, myentityname )¬
into the_response
Put Volumes() into temp
put the_response&return&temp into the_response
ADSPTalk client, the_response
end if
end return_volume_list
Listing 1. Stack Methods for HyperServer
