+++ /dev/null
-The last version of AsyncSocket from Dustin Voss was version 4.3 released on 2005-11-23. This document lists the bug fixes provided by Deusty Designs, prior to the creation of the Google Code project.
-
-CHANGES IN VERSION 4.3.1:
-
-Bugfix:
- If user called acceptOnPort:0, then the OS would automatically pick a port for you.
- This is what is supposed to happen, except that it would pick a different port for IPv4 and IPv6
- Added code to make sure both protocols are listening on the same port
-
-Added comments in many places
-
-Altered bits of code to match Apple's coding style guidelines
-
-Renamed method "attachAcceptSockets" to "attachSocketsToRunLoop:error:"
-
-
-
-
-CHANGES IN VERSION 4.3.2
-
-Removed polling - it's not needed
-
-Added another delegate method: onSocket:didReadPartialDataOfLength:tag:
-Often, when using the AsyncSocket class, it was important to display a progress bar to the user.
-This was possible using Timers, and calling progressOfRead, but it wasn't the easiest solution.
-This delegate method will allow for automatic notification when using readToLength: or readToData:
-
-
-
-
-CHANGES IN VERSION 4.3.3
-
-Bugfix:
- The methods connectedHost, connectedPort, localHost, and localPort all assumed IPv4 connection.
- In other words they all assumed theSocket was valid, causing a crash when the OS connected via IPv6.
- Updated all methods to properly check either theSocket or theSocket6.
-
-Bugfix:
- In the doStreamOpen method, there was an assumption that IPv4 was used and thus a valid theSocket variable.
- This was not always the case, causing this to fail:
- CFSocketCopyPeerAddress(theSocket)
- Fixed the problem by simply using the connectedHost and connectedPort methods.
-
-Tweak:
- Added safety check in addressPort: method:
- if (cfaddr == NULL) return 0;
-
-Tweak:
- The kCFStreamPropertyShouldCloseNativeSocket was previously getting set in the configureStreamsAndReturnError: method.
- This may have been OK, but it would have caused a problem if the following sequence occurred:
- A socket was accepted and doAcceptWithSocket: method was called,
- This method then encoutered an error while attaching the streams to the run loop.
- If this sequence happened, the BSD socket would not have been closed.
- So I moved this into the createStreams... methods.
-
-
-
-
-CHANGES IN VERSION 4.3.4
-
-Bugfix:
- In doReadTimeout: the code properly calls endCurrentWrite and then closes with an error.
- In doWriteTimeout: the code was calling completeCurrentWrite and then closes with an error.
- This resulted in the delegate being told that his write completed (when it didn't)
- immediately prior to disconnecting with an error.
-
-
-
-
-CHANGES IN VERSION 4.3.5
-
-Added support for accepting on IPv6 address.
-
-Bugfix:
- In acceptOnAddress, changed dataWithBytesNoCopy to dataWithBytes.
- This was needed because the bytes were about to go out of scope.
-
-Bugfix:
- Added return statement to doStreamOpen after closewithError call.
- This was needed or else the didConnect delegate could potentially get called
- immediately after willCloseWithError and didClose.
-
-Bugfix:
- We were receiving several reports of crashes in AsyncSocket.
- The problem seemed to be that, in specific circumstances,
- the readStream callback and/or writeStream callback would be invoked AFTER
- the readStream and writeStream were closed.
- This isn't supposed to happen, however we did find evidence that it was an issue several years ago.
- It was assumed that the problem has since been fixed.
- Perhaps the problem still exists, but only in very rare cases which we just happened to be encountering.
- In any case, we used the same precautions that were used previously.
- In the close methods, we specifically unregister for callbacks now.
-
-
-
-
-There have been several more bug fixes and changes. Please consult the google code changes list:
-http://code.google.com/p/cocoaasyncsocket/source/list
\ No newline at end of file
OSDN Git Service
