>> 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.
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
