Re: Socket stuck with puts over ADSL line

Hillel wrote:

> Thanks, Melissa. I already tried the [filevent writeable] method. The
> socket registers as writeable with no problems, and the program still
> gets stuck with the puts command within the filevent writeable
> callback.

Is the socket configured as -blocking 1? I'm not sure how Tcl performs
the handoff to the OS. When you call send() on a non-blocking socket,
it will return immediately with the amount of data buffered (placing
data in the buffer until it is no longer writable). I don't know how
Tcl implements sockets, but this would seem to be the sensible approach,
and I would expect the Tcl-level [puts] to behave similarly, with a
level of abstraction. Where the internals continue to attempt to send()
the data until it is all gone, and make the channel unwritable when an
OS-level send() becomes unwritable. It wouldn't become unwritable until
a send() returned less than the amount requested to be sent. And you
can't determine that it's unwritable until you make at least one attempt.

Now, the remote end could hose this all by dropping the connection
silently (without performing a proper TCP shutdown handshake). Your
local buffer would fill rapidly, and eventually become unwritable. Is
there a filtering node on the route to this ADSL host? Perhaps the ADSL
modem itself is configured to block/drop inbound traffic.

Or general network congestion could be the culprit.

You said "everything else works," except sending large files. How
large? How are you sending them? Are you breaking them up into single
lines and calling [puts] on each line? If so, I'd recommend against
that ([puts] the whole file at once).

> I have to wonder about using full buffering with a small buffer size.
> If the data being sent in the puts command is a lot larger than the
> socket buffer as set with fconfigure, will the system send each
> buffered portion across the WAN as its own TCP packet, or will the OS
> reassemble the whole thing and then break it up again by the network
> MTU value before sending it over the WAN?

I think that is entirely up to the OS. It's not as though you'd have
any more control over this writing native code, unless you wrote your
own TCP stack.

My understanding is that Tcl will pass the data to the OS's TCP stack
whenever the Tcl buffer is full, or whenever you [flush] it. How much
data gets put into the OS's buffer at a time, and how large or small the
MTU of the ultimate packets is going to depend on the OS itself. So, I
believe, the latter: the OS will assemble all of the data it has at any
given time, and break it down into what it believes to be optimal packet
sizes.

> If the former, then this
> could be used to overcome packet fragmentation and reassembly problem
> due to the reduced effective MTU from the PPPoE and VPN on this one
> ADSL line. If the latter, then I have a big problem as the route to
> the DSL network is shared by other remote sites that do not have this
> restriction and reducing the MTU at the server end could seriously
> affect network performance to other sites. I am using TCL 8.3.5 on SCO
> OpenServer 5.0.7.

Either way, I think you have a problem. Essentially, it sounds like you
have a TCP level problem. Any MTU issues should be resolved at the OS
network layer. If you have a connection so unreliable that TCP can't
manage to send packets, you probably need to break out the network
analyzer tools, because whether you use Tcl, C, or anything else, the
best you're going to be able to do is manage the errors gracefully at
the application level.

In other words, debug your connection, or nothing will work. If basic
connections work, try sending large files over the VPN using a proven
method, perhaps ftp or scp. Can they be sent in one direction
successfully but not the other? Grab tcpdump or something similar.
When a connection gets hung up, which side is waiting? For what? An
ACK that never comes? If one side appears to be inexplicably waiting to
send data, NOT waiting on anything, is there a point where the
application has overwhelmed the TCP stack with numerous calls to send
very small chunks of data rapidly?

I don't know, just throwing out ideas.

-- 
MKS