--- /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 MANY 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