Re: Macnetworkprog Digest, Vol 6, Issue 20
Re: Macnetworkprog Digest, Vol 6, Issue 20
- Subject: Re: Macnetworkprog Digest, Vol 6, Issue 20
- From: "eric v.d.berg" <email@hidden>
- Date: Sat, 7 Feb 2009 18:28:06 +0100
2009/2/4, email@hidden
<email@hidden>:
> Send Macnetworkprog mailing list submissions to
> email@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.apple.com/mailman/listinfo/macnetworkprog
> or, via email, send a message with subject or body 'help' to
> email@hidden
>
> You can reach the person managing the list at
> email@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Macnetworkprog digest..."
>
>
> Today's Topics:
>
> 1. OTRcvDisconnect failing with OTResult (-3221) (Lyndsey Ferguson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 4 Feb 2009 13:53:40 -0500
> From: Lyndsey Ferguson <email@hidden>
> Subject: OTRcvDisconnect failing with OTResult (-3221)
> To: email@hidden
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> Hello everyone,
>
> I'm dealing with a problem in our application. Our application
> attempts to connect to another using OTConnect. Sometimes, as
> OpenTransport programmers know, OTConnect can fail with a return value
> of kOTLookErr. According to the documentation, the proper thing to do
> is to call OTLook on the endpoint and if the result is T_DISCONNECT,
> the proper thing to do is to call OTRcvDisconnect to clear the
> disconnection event. This is what we do.
>
> However, it has become apparent that this OTRcvDisconnect is not
> working. When a T_DISCONNECT is received, and our application tries to
> clear the event and close the endpoint, the connection stays open
> according to the Open Files and Ports window of the Activity Viewers
> tool. And not for 1/3rd of a second, but forever. Eventually, our
> application runs out of file descriptors and can no longer open other
> necessary files. This is a big problem for us.
>
> I believe that this is a new problem for us as of at least Mac OS X
> 10.5.4.
>
> Am I calling OTRcvDisconnect correctly? I believe I must pass in the
> endpoint that was trying to connect to properly clear the disconnect
> event. The documentation tells me that I can send NULL or a pointer to
> a TDiscon call to get the data. The discon.reason is most often 61
> (ECONNREFUSED), but once it was 60 (ETIMEDOUT). Both make sense and I
> should be able to properly disconnect from the other endpoint.
>
> OTRcvDisconnect returns -3221 when I try and call it like so:
>
> fStatus = OTConnect(fConnectionRef, &sndCall, NULL/* &rcvCall*/);
> if (fStatus != kOTNoError) {
> OTResult result = 0;
> if (fStatus == kOTLookErr) {
> result = ::OTLook(fConnectionRef);
> if (result == T_LISTEN) {
> //OTRcvConnect(fConnectionRef, &rcvCall);
> LOG_INFO("TMacSocket", "Another connection request from another
> endpoint has interrupted execution of OTConnect.<BR>\n");
> }
> else if (result == T_DISCONNECT) {
> TDiscon discon;
> LOG_INFO("TMacSocket", "Received disconnect request.<BR>\n");
> char theMessage[256];
>
> OTResult rcvDisconnectResult = ::OTRcvDisconnect(fConnectionRef,/
> *NULL*/ &discon);
> // rcvDisconnect is always -3221 == kEINVALErr == invalid argument
> sprintf(theMessage, "OTRcvDisconnect result: %s.<BR>\n",
> OTEventCodeError(rcvDisconnectResult));
> LOG_INFO("TMacSocket", theMessage);
>
> sprintf(theMessage, "The disconnect reason is: %ld.<BR>\n",
> discon.reason); // ECONNREFUSED
> LOG_INFO("TMacSocket", theMessage);
> }
> }
>
> if (fStatus != kOTNoError) {
> OSStatus status = fStatus;
>
> //this->Close();
>
> if (status == kOTLookErr) {
> throw TSocketException("TMacSocket::Connect",
> OTEventCodeError(result));
> }
> else {
> throw TSocketException("TMacSocket::Connect", OTError(status));
> }
> }
> }
>
> Does anyone have any suggestions? I know that OpenTransport is a
> deprecated system, but I cannot replace it at this point for reasons I
> cannot go into.
>
> I hope that I am just calling it incorrectly.
>
> Thanks for all and any suggestions, in advance.
>
> Sincerely,
> Lyndsey Ferguson
>
>
>
> ------------------------------
>
> _______________________________________________
> Macnetworkprog mailing list
> email@hidden
> http://lists.apple.com/mailman/listinfo/macnetworkprog
>
> End of Macnetworkprog Digest, Vol 6, Issue 20
> *********************************************
>
--
Verzonden vanaf mijn mobiele apparaat
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden