Unblocking FtpView

The most obvious result of switching our sockets to nonblocking is significantly improved performance. With blocking sockets, we specified timeouts of five seconds. This meant that if a function were going to fail because the network operation did not complete in time, it would take five seconds.

With nonblocking sockets, these function calls fail immediately. Thus we finish our receive loops faster—the last iteration of the loop that would previously block until the timeout expired now immediately returns an error. This saves us five seconds every time a receive operation fails because there’s no data to receive.

As it turns out, our application already has the right architecture to support nonblocking mode. In Chapter 10, we implemented a polling architecture that checked each socket’s I/O readiness before we attempt read or write operations. This is exactly the architecture needed for nonblocking sockets.

We will need to change how we handle connections. In previous versions, the application attempted to connect and blocked until the three-way handshake completed or until a timeout occurred. In nonblocking mode, we need to make several calls to NetLibSocketConnect before the connection is actually established.

The first call to this function initiates the three-way handshake and returns the error netErrWouldBlock. Subsequent attempts return this error until the connection is established. Then, the next call to NetLibSocketConnect returns netErrAlreadyConnected ...

Get Palm OS Network Programming now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.