[Twisted-Python] How do I debug this network problem?

[Peter Westlake]

>> I've put in the dataReceived, and the answer box does*not*make it
>> into the Protocol. There are two entries in
>> protocol._outstandingRequests: {'2189': <Deferred...>, '2188':
>> <Deferred...>} and the log output shows 2186, 2187, 218a, 218b, ...
>
> So, wait a second.
>
> You said you're looking at tcpdump, and it's showing you that your
> outstanding requests - in this case, 2188 and 2189 - are in fact being
> answered. But then you say you're looking at the dump from
> dataReceived, and seeing that not only are 2188 and 2189 not being
> answered from that layer, but 218a and 218b *are* being answered?
>
> Simply put: that should be impossible. TCP is an ordered stream. If
> you received answers to 2188 and 2189 on the wire in tcpdump, you
> should see those come back to dataReceived first. What kind of
> transport is this hooked up to? A regular socket? Is there TLS
> involved? Did you run tcpdump for that same session?

No TLS, just TCP, created with
twisted.application.internet.TCPClient(host, port, protocolfactory).

I didn't record this session with tcpdump, but from a previous one I can
say that yes, some Deferreds are left hanging around waiting for a
response while subsequent ones have already received one. There was no
interruption or irregularity in the TCP stream.

tcpdump: 2186, 2187, 2188, 2189, 218a, 218b

dataReceived: 2186, 2187, 218a, 218b

_outstandingRequests: {2188, 2189}

So as you say, TCP must have delivered the data to someone, or at least
believe it has. How much code is there between there and dataReceived? I
imagine most of it is in the kernel?

Peter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20141113/b3770ca2/attachment-0002.html>