Bob Arning <arning at charm.net> wrote:
> I ran into a problem recently where a large chunk of data was being sent through a Squeak socket over a dial-up line at 9600 baud. Socket>>sendData: requests the VM to send as much as possible and waits up to 20 seconds for the send to complete. Since the new Mac VM seems willing to send up to 64K each pass, this means that unless the network is transmitting at 3200 BYTES per second, a large request will timeout. Clearly 9600 baud won't do that.
> 
> I was able to get it running fine by increasing the timeout value and dropping the max data sent each pass, but that's not pretty. It means that real timeouts, when they happen, will be longer and fast networks may not be as fully utilized since more calls are made to send the same data. It also leaves open the question of how slow a network can be before it stops working again.
> 
> It would be nice if there were some way of asking if packets are being sent in a timely fashion - whatever that means for a given network connection.
> 

Timeouts aren't handled incredibly well in Squeak networking apps right
now.  Here are two general approaches I would suggest for dealing with
them in new software.

First, if it's a client app, *don't time out*!  There should be a way
for the user to cancel an outstanding operation, anyway, and given such
a mechanism, you can just let the user wait however long they feel like.

Second, if you must have a timeout (for instance, if no user is
present), look at larger goals than individual sends and receives.  If
you look at individual sends and receives, then you can let a connection
keep going that is only sending 1 byte every 10 seconds.  Assuming that
you would rather kill such a slow connection, do something like timeout
if an entire request takes longer than 2 minutes.

On the latter angle, it's true that most Squeak network interfaces
require you to specify a timeout with each network operation (or to use
a default value).  However, the value you supply doesn't have to be a
constant.  In fact, it makes a lot of sense to initialize a "target"
time value, and to use that same target as the timeout arument for every
network call until you reach the target--this has the effect that the
first timeout will be huge, and subsequent ones will automatically be
smaller as needed.

Also, by the way, programmers are perfectly free to use the
"sendSomeData" and "getSomeData" variants, and to poll "sendDone" and
"dataAvailable" explicitly.  You don't have to use the builtin messages
like "waitForDataUntil:".


-Lex