Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jmeter.apache.org
Subject: Re: TCP Sampler
To: dev@jmeter.apache.org
References: <CAH9fUpaQWWVOCkhSyzyZUEnJ2OsBeKUDL669uiywysFdYjC2iA@mail.gmail.com>
From: Andrey Pokhilko <apc4@ya.ru>
Message-ID: <d8610129-3974-5134-555d-59f315db15d6@ya.ru>
Date: Tue, 24 Oct 2017 09:11:59 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAH9fUpaQWWVOCkhSyzyZUEnJ2OsBeKUDL669uiywysFdYjC2iA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
archived-at: Tue, 24 Oct 2017 06:12:12 -0000

Hello,

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
sampler.

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.
>
>
>