SRP_TcpClient "SEND"

prattspets

When I attempt to send data to a server using the utility SRP_TcpClient, the function breaks with the runtime error in the OI Debugger:
"ENG0016: SRP_TCPCLIENT, line 75. Non-numeric data when numeric required. Zero used."
I went back to test it with the example code on the website using the debugger to see what is happening on each line of code:

// Connect to a local socket, send data, and then close
TcpClientHandle = 0
If SRP_TcpClient(TcpClientHandle, "CONNECT", "127.0.0.1", "7777") then

// Send the string length in binary
SRP_TcpClient(TcpClientHandle, "SEND", \0000000D\)

// Send the string
SRP_TcpClient(TcpClientHandle, "SEND", "Hello, World!")

// Close
SRP_TcpClient(TcpClientHandle, "CLOSE")
end

I found that when it tries to send the \0000000D\, it gives the same runtime error. I have tried the following commands with the following results in a socket test software as the listening server:

SRP_TcpClient(TcpClientHandle, "SEND_SES", "Hello, World!")
Result: the data transmits with Hex 04 00 00 00 0D before the "Hello, World!" chars

SRP_TcpClient(TcpClientHandle, "SEND", 13)
SRP_TcpClient(TcpClientHandle, "SEND", "Hello, World!")
Result: The first line will not trigger a runtime error, but no data is passed to the server. The second line results in the runtime error.

What am I missing?

KevinFournier

What are you communicating with? SRP Engine Server? Something else?

prattspets

I am doing the testing by communicating with an application called SocketTest. I ultimately will be communicating with a Verifone application.

KevinFournier

This appears to be my fault. I was using a DLL definition keyword that doesn't work the way I expected. Admittedly, the SEND service never got fully vetted since we only ever needed the SEND_SES service. At any rate, download and install SRP Utilities 1.5.8 RC2 and see if it behaves better.

prattspets

That did it. It works wonderfully! Thanks!

prattspets

Does this utility have a way to read a response from the server?

DonBakke

Not at this time. The client only sends data but it does not act as a listener or return data synchronously. Does Verifone not have any easier APIs, such as REST or another HTTP-based solution?

prattspets

It appears that this is the only method that they have of communicating from the Point of Sale to the Verifone secure device that the credit card is swiped/dipped on. This is for credit/debit card present transactions. There are other gateways that do communicate with HTTP-based solutions, but those are only for credit card NOT present transactions, typically online sales. This tool is handy to get me half way there. I'll just have to jump through some hoops to receive the response Xml that the device server generates.

DonBakke

I take it that you decided ChargeItPro wasn't an acceptable solution?

prattspets

I currently use ChargeItPro and it works pretty good. There are still quite a few bugs they are working out with the current solution they have, so I am just looking at other options. When it comes to credit card rates, it's good to have options.

DonBakke

Feel free to email me privately on this as I would be interested to pursue this matter. I am not aware of any bugs and we have a number of implementations. If I can help you or help guide ChargeItPro I'd be happy to do so.

KevinFournier

Download 1.5.8 RC3. This version includes the "RECEIVE" command. It works like so:

BytesToRead = 10 Data = SRP_TcpClient(Handle, "RECEIVE", BytesToRead, BytesActuallyRead)

You pass in the number of bytes you want to read, the BytesActuallyRead variable tells you how much was actually read. NOTE: This method will wait for data. So, if there is no data available, it will sit there waiting for it. If it returns 0 bytes read, then the connection to the server ended.

prattspets

Thanks for putting this additional functionality to this utility. It works great! The sample code you put in your last post needs to be revised to put the Handle as the first parameter and the command "RECEIVE" as the second parameter.

KevinFournier

Revised. Thanks.

Truth be told, I'm actually on site at a client's, so I couldn't really test it. Glad it worked.

prattspets

I did find that the application will lock up if BytesToRead is set to more bytes than the server has sent out as a response. I tested setting a loop to read one byte at a time, and once the whole response was received from the server, the next "RECEIVE" command resulted in the application locking up.

KevinFournier

That is consistent with Socket specifications. When receiving on any socket, the application waits until the requested amount of data is received or the socket disconnects.