jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Pokhilko <>
Subject Re: TCP Sampler
Date Tue, 24 Oct 2017 06:11:59 GMT

I think you are right. That's natural part of generic TCP testing, you
have to be aware of all these bytes and bits. Definitely not for newbie,
unless you have friendly TCPClientImpl. The biggest problem here is
binary traffic. JMeter operates only with strings, while in TCP you need
to work with binary. Any _generic_ GUI you would put to solve this, will
still be quite complex. But if you ask for idea, I'd say "Provide text
field to type HEX octets sequence and show some binary representation of
result in live packet preview".

Another usability problem of TCPClientImpl is that it has no GUI per
implementation, which is quite confusing. But once you think of
implementing GUI for it, it becomes equal to standalone sampler, by
amount of effort. And having standalone sampler is preferred, because
you have full control on different aspects of your TCP traffic and GUI.

So IMO TCP Client is close to its optimal spot: allows some testing till
you need to write custom protocol handler, then you migrate towards own

Andrey Pokhilko

23.10.2017 22:52, Philippe Mouawad пишет:
> Hello,
> I am currently playing with TCP Sampler and have noticed some quite
> unfriendly things:
>    - Adding carriage return is not easy and you need to hack it with some
>    PreProcessor:
>       - vars.put("LF",URLDecoder.decode("%0D", "ASCII"));
>       vars.put("CR",URLDecoder.decode("%0A", "ASCII"));
>       - And then in TCP Sample:
>          - hello${CR}${LF}
>       - => Shouldn't we add something to make it easier ? Ideas ?
>       - Handling EOL with Cariage return is also weird, why eol is set to
>    1000 instead of 10 for example ?
> Component looks very complex to use for a newbie, and even for advanced
> users.

View raw message