On Aug 11, 2011, at 7:43 PM, exar...@twistedmatrix.com wrote:
> This will always be a somewhat unreliable way to test a remote process's
> handling of packetization, since there are still two TCP/IP stacks which
> can mess around with the data in a variety of ways, but it's as good as
> you can
On 09:54 pm, tobias.oberst...@tavendo.de wrote:
>sorry, my question wasn't clear:
>
>I do already disable Nagle by setting TCP NoDelay.
>
>And I do a reactor.select(0), which sometimes breaks I guess
>because of reactor reentry not expected, and it will break
>when the reactor is not select() based
> but again, the OS will split
> things up across TCP packets however you want.
That should read "however *it* wants".
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
> sorry, my question wasn't clear:
>
> I do already disable Nagle by setting TCP NoDelay.
>
> And I do a reactor.select(0), which sometimes breaks I guess
> because of reactor reentry not expected, and it will break
> when the reactor is not select() based I guess.
>
> So the question is: is there
sorry, my question wasn't clear:
I do already disable Nagle by setting TCP NoDelay.
And I do a reactor.select(0), which sometimes breaks I guess
because of reactor reentry not expected, and it will break
when the reactor is not select() based I guess.
So the question is: is there an alternative
> so there is no Twisted sanctioned (reactor independent and reentry safe)
> alternative to disable nagle (tcp nodelay) and doing a select()?
You can disable nagle in Twisted, if that's the question
(transport.setTcpNoDelay(True)). But you can't determine TCP packet size,
that's up to the operatin
yes. for FF and Chrome, and other WebSockets clients
On 11.08.11 23:40, "Christopher Armstrong" wrote:
On Thu, Aug 11, 2011 at 5:18 PM, Tobias Oberstein
wrote:
well, it does not necessarily correspond, but from what I see on tcpdump with
loopback device and on LAN (with TCP NoDelay set), it p
On Thu, Aug 11, 2011 at 5:18 PM, Tobias Oberstein <
tobias.oberst...@tavendo.de> wrote:
> well, it does not necessarily correspond, but from what I see on tcpdump
> with
> loopback device and on LAN (with TCP NoDelay set), it practically works.
>
> the problem with your suggestion: I want to test
so there is no Twisted sanctioned (reactor independent and reentry safe)
alternative to disable nagle (tcp nodelay) and doing a select()?
ps: to give an example of how that was at least practically useful in what i
try to do .. and not only blabbing away:
http://www.tavendo.de/autobahn/testsuit
ahh, I felt I missed sth;) thx .. I'll look into that
On 11.08.11 23:16, "Christopher Armstrong" wrote:
On Thu, Aug 11, 2011 at 5:13 PM, Tobias Oberstein
wrote:
For a test driver for a TCP-based protocol (written in Twisted) I want to send
data to a
receiver as fast as the receiver can consu
well, it does not necessarily correspond, but from what I see on tcpdump with
loopback device and on LAN (with TCP NoDelay set), it practically works.
the problem with your suggestion: I want to test the other end .. and that is
not Twisted (its i.e. Firefox .. the protocol to test is WebSockets)
> However, isn't there a simpler way (without application level flow
> control)?
>
> In the end, the sender TCP stack must have knowledge of it's window size
> ..
> is there a way to get at that info?
>
> What is the recommended way?
Transports provide the IConsumer interface, to which you can hoo
On Thu, Aug 11, 2011 at 5:13 PM, Tobias Oberstein <
tobias.oberst...@tavendo.de> wrote:
> For a test driver for a TCP-based protocol (written in Twisted) I want to
> send data to a
> receiver as fast as the receiver can consume data, but not faster.
>
> Apparently, a naive loop which just does tr
On Thu, Aug 11, 2011 at 5:06 PM, Tobias Oberstein <
tobias.oberst...@tavendo.de> wrote:
> For testing implementations of a TCP-based protocol, I am testing
> if an implementation is agnostic wrt to in what chops in receives
> octets from the wire ("stream clean").
>
> To do that, I force out octet
For a test driver for a TCP-based protocol (written in Twisted) I want to send
data to a
receiver as fast as the receiver can consume data, but not faster.
Apparently, a naive loop which just does transport.write() does not work. When
I do
reactor.select(0) between the writes, it somehow works,
For testing implementations of a TCP-based protocol, I am testing
if an implementation is agnostic wrt to in what chops in receives
octets from the wire ("stream clean").
To do that, I force out octets from the protocol test driver (written
in Twisted) in differently sized chops, down to single oc
16 matches
Mail list logo
