Thanks, would be happy to adopt the suggested approach and delegate the protocol-specific conversion to a new TCPClient implementation with selection from the TCPSampler GUI to support test plans using more than one.
This would leave the TCPClient Interface read()/write() method signatures unchanged as strings would be passed in and out. Not sure whether setup parameters would be necessary given this approach as TCPClient Implementation would be specific to protocol/character set in use? -----Original Message----- From: sebb [mailto:[EMAIL PROTECTED] Sent: 08 October 2008 13:04 To: JMeter Developers List Cc: Mike Cronin Subject: Re: TCP Sampler Extension to support length-prefixed binary data On 08/10/2008, Oghie Sheehy <[EMAIL PROTECTED]> wrote: > Hello, > > We have a requirement to test a TCP service which expects requests in > length-prefixed binary form and responds with data structured in the same way. Is this a proprietary service, or are there several such services? > We have experimentally extended the TCP sampler code to support this by > adding a "Length Prefixed Binary Data" option to the GUI. > > With this option checked: > > a) The TCPSampler sample() method treats the input request text as a > hexadecimal string and converts it to a byte array. > Conversely it reads a byte array and converts it to a hexadecimal string. > > b) The TCPClient has been extended to support the following new methods: > void write(OutputStream os, byte[] b); > byte [] readLengthPrefixed(InputStream is); > The readLengthPrefixed method expects the first 2 bytes from the stream to > contain the length (binary) of data to follow and reads this number of > subsequent bytes returning a byte array containing both the length and data > bytes. > > e.g. > Request/Response String: > "002d482d2d2d3e454e414320544350495020484541525420424541543c2d2d2d5443504449414c2056312e30312020" > Input/Output Byte Array: [0x00,0x2d, 0x48, ......, 0x20] > > This is a simple but limited approach, it does not permit the transmission > of non-length prefixed binary data nor does it support length prefixed > character data. Finally as it is implemented the length prefix must be input > as two byte binary (input as hexadecimal string) rather than being calculated > or input as character decimal. > > There are options to make the solution more flexible but before spending > time on these we would like to know whether the minimal approach taken above > would be considered for inclusion in a future JMeter release? > It sounds fairly straightforward, and would not affect existing test plans. I'm just wondering if it might be cleaner to add the functionality as a new TCPClient implementation? At present the TCPSampler only supports a single implementation that is defined via a property, but it could be enhanced to fetch the name from the GUI to support test plans which require more than one implementation. It might be necessary to extend the TCPClient interface to support some kind of setup method to allow parameters to be passed in; these would need to be added to the TCP Sample GUI. The advantage of this approach would be that there should be no need to change the TCP Sampler further in order to accommodate new protocols. I have just realised that the TCPClient interface read() method was badly designed; it should have returned a byte array. At present both the client and the sampler have to do String<>byte conversions - and there is no provision for specifying the character set to be used. However, that does not affect your current requirements. > Thanks, > Oghie. > > > > > > > ********************************************************************** > > E-mail disclaimer > FEXCO Dynamic Currency Conversion Limited, registered in Ireland, No. > 246289. Registered Office: FEXCO Centre, Iveragh Road, Killorglin, Co. Kerry. > > This message, including any attachments, is confidential. If you are not the > named recipient, please contact the sender and delete the email from your > system. > > ********************************************************************** > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
