Socket>>sendData: and slow networks

John M McIntosh johnmci at smalltalkconsulting.com
Thu Jun 29 11:04:15 UTC 2000


on 6/28/00 2:44 PM, Bob Arning at 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

Hi Bob, it's more complicated at the lower level in the Mac open transport
code. You see I copy and hand off the data to the send data call which
happens to buffer 64K (I think) of data within the transport layer. If you
look at the socket options you can see what the socket buffer sizes are on
the macintosh, these of course are adjustable in the 2.8 Mac VM.

This means at the point when I get notification that a flow restriction
exists, which remember could be coming from the other side if you are
overrunning the peer (doubtful). Then we could have WAY more than 64K of
data in flight. The flow restriction is lifted when either congestion in the
lower layers of OT are cleared, or the other side starts accepting more
data. When this happens we consider the send done, but data still lurks
lower down, but now we can accept more data to send.

However as you point out this might cause a timeout failure since now you
are waiting on 64k+ of data to be transmitted.

>, 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.

I'm not sure I follow this. If you set a 300 second timeout and it occurs
then is the other side dead or just congested? How do you tell?  Perhaps
there isn't a good answer here.

> 
> 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.

This is hard since you don't know when the packet actually arrives at the
other side in TCP/IP, unless the other side helps. In the Mac VM the
objective is to accept data from Smalltalk code as fast as possible and
buffer it to the transport layer which runs async, this would skew numbers
if you are attempting to look at flow rates, since it will accept the first
64k really really fast.

> 
> Any ideas?
> 
> Cheers,
> Bob
> 

PS I've been writing some notes on the OT code you can find it here
http://www.smalltalkconsulting.com/html/OTNotes1.html

--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================
Custom Macintosh programming & various Smalltalk dialects
PGP Key: DSS/Diff/46FC3BE6
Fingerprint=B22F 7D67 92B7 5D52 72D7  E94A EE69 2D21 46FC 3BE6
===========================================================================





More information about the Squeak-dev mailing list