iOS实例开发源码——mattb-netgame-281d7a7.zip

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