You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Philippe Mouawad <p....@ubik-ingenierie.com> on 2017/10/23 19:52:07 UTC
TCP Sampler
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.
--
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie
Re: TCP Sampler
Posted by Andrey Pokhilko <ap...@ya.ru>.
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 <ap...@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.
>>>
>>>
>>>
>>
>
Re: TCP Sampler
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <ap...@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.
> >
> >
> >
>
>
--
Cordialement.
Philippe Mouawad.
Re: TCP Sampler
Posted by Andrey Pokhilko <ap...@ya.ru>.
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.
>
>
>