jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Pokhilko <a...@ya.ru>
Subject Re: TCP Sampler
Date Tue, 24 Oct 2017 10:54:28 GMT
Fairly, this is for quite advanced users IMO, so I don't think it worth
effort. EOL marks usually is a minor issue.

I'm saying this from my personal experience, it was always ending in
custom samplers.

Andrey Pokhilko

24.10.2017 11:29, Philippe Mouawad пишет:
> Thanks for your valuable answers.
> Do you think :
>
>    - Adding an End of Line as Hex for request. This field would be used by
>    plugin to append it to request
>    - Renaming End Of Line field as End of Line for response
>    - Adding the helper you propose
>
> would make things easier ?
>
>
> Regards
>
> On Tue, Oct 24, 2017 at 8:11 AM, Andrey Pokhilko <apc4@ya.ru> wrote:
>
>> 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.
>>>
>>>
>>>
>>
>


Mime
View raw message