time@tbomb.ice.com (Tim Endres) (08/28/90)
I am using the CTB for AppleTalk ADSP communications, and
am having difficulty with the ADSP connection ritual.
On the server side, I am doing something like:
{
CMNew()
CMListen(ASYNC);
while (NOT accepted)
{
CMStatus()
if (statusListenPend == FALSE && statusIncomingCallPresent == FALSE)
{
printf("ERROR listener closed unexpectedly.");
}
else if (statusIncomingCallPresent == TRUE)
{
CMAccept();
accepted = TRUE;
}
}
Communicate..... (Calls to CMRead(), CMWrite(), CMConfig(), etc...).
}
Excusing the hideous psuedo-code....
Does this look right? Do I need A CMOpen() in there?
How do the status flags work here? Is my check valid?
Right now, my first attempts at communication lock the
server and the client. This appears to be virtually
undocumented.
tim.
-------------------------------------------------------------
Tim Endres | time@tbomb.ice.com
ICE Engineering | ...uunet!oxtrap!tbomb!time
8840 Main Street |
Whitmore Lake MI. 48189 |
---austing@Apple.COM (Glenn L. Austin) (08/29/90)
time@tbomb.ice.com (Tim Endres) writes: >I am using the CTB for AppleTalk ADSP communications, and >am having difficulty with the ADSP connection ritual. >On the server side, I am doing something like: >{ > CMNew() > CMListen(ASYNC); > while (NOT accepted) > { > CMStatus() > if (statusListenPend == FALSE && statusIncomingCallPresent == FALSE) > { > printf("ERROR listener closed unexpectedly."); > } > else if (statusIncomingCallPresent == TRUE) > { > CMAccept(); > accepted = TRUE; > } > } > Communicate..... (Calls to CMRead(), CMWrite(), CMConfig(), etc...). >} As I recall... statusListenPend and statusIncomingCallPresent are NOT linked together. Remove the "&& statusIncomingCallPresent" from the first test. If the ListenPend is false, it doesn't matter what the IncomingCallPresent bit is and vice versa. In fact, unless you explicitly call CMClose on an infinite CMListen (timeout = -1), Listen should (and does) go on forever! -- ----------------------------------------------------------------------------- | Apple Computer has no connections with any of my postings. | ----------------------------------------------------------------------------- | Glenn L. Austin | "Turn too soon, run out of room, | | Auto Racing Enthusiast and | Turn too late, much better fate" | | Macintosh Programmer | - Jim Russell Racing School Instructors | | Internet: austing@apple.com | "Drive slower, race faster" - D. Waltrip | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------
time@tbomb.ice.com (Tim Endres) (08/31/90)
Well, after fixing my hard drive, and getting both machines back on line, I have solved this mystery, An important feature of the ADSP tool in documented in these paragraphs. Well, I have managed to solve the problem. Boy, talk about a lack of documentation on CMListen! The problem, in my case, was that I had both connections performing a "flush_connection()" simultaneously upon establishing the connection. This was a carry over from the old "Serial Manager" days, where I religously had to flush modem garbage from the incoming data stream. I implemented the flush call with a call to CMRead() with a specified timeout. Thus, I was trying to empty any available data using a timeout to avoid hanging for data that was not there. BUT, for some reason, when both parties of an ADSP connection try to simultaneously CMRead(), it is certain HANG for both parties. When I removed the flush_connection() call, all worked well. Further, I think using the CMReset() call for the flush_connection() is the "correct" answer, and is what I am doing now. Be aware of this feature of the ADSP tool. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uunet!ice.com!time 8840 Main Street | Whitmore Lake MI. 48189 | --- Disclaimed.