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 <[email protected]> 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. >>> >>> >>> >> >
