Simple example of a TCPSocket

I’m trying to use a TCPSocket to exchange data between a server I wrote and a Xojo app I’m working on. What I need to do is to send the data one line at time, get an ‘OK’ from the server, and then send the next line. But the documentation for TCPSocket is confusing and the example project is too.

Can anyone give me a simple example of how to send a message to the server then check if I got ‘OK’ back before sending the next message? Sorry for the annoying and simple question but I’ve never used TCPSocket and I’m fairly newish to Xojo networking.

Thanks!

The server you wrote. Tell us more about that. How do you expect communications to occur? Is this a local server or sitting on the internet?

It’s local. The server is .NET code that I’m structuring very simply. A typical transaction might go like this once connected:

SERVER: OK
CLIENT:
SERVER: OK
CLIENT:
SERVER: OK
CLIENT: END_TRANSACTION
SERVER: OK

Pretty simple stuff as I’m going to be relaying information elsewhere from the server. Does that help?

Oops, I see you tried the example, I’ll go back to sleep :wink:

I would start with the example Communication/Internet/SynchronousTCPSocketExample. The MainWindow is exactly how I would start this project. It may not be exactly what you want, but it’s very close.

We could give you code, but it’s been my experience that those just get code keep asking for code without understanding it. Start small and simple and built up from there.

I mean, you’re not really giving us much to go on with what you’ve actually tried other than you said you looked at the example. Was it connecting? Was the server not getting any data? Was the server not sending data back? Were there any error codes?

Thank you, Bob. I wasn’t really looking for code as I’d rather figure out the code myself but more of a ‘the code goes here’ type of answer. I wasn’t clear on that really. But I think I understand this a bit better now and, let me ask if this is correct:

Once my socket is connected, I will be notified via the DataAvailable event when data is ready to be read. So, when my server sends the initial “OK” to start the transaction, I’ll know it by this event firing. I’m assuming that ALL looped communication for this transaction will happen in the DataAvailable event handler, correct? So I will have a variable (defined outside of the handler) that keeps track of which step in the transaction I am in. Each time I get DataAvailable firing, I look at this variable and look at the actual data available. If the server said “OK” then I proceed to another socket.writeln(Data as String) for the next step. I do this until all my data is sent, the close() the socket and be done.

Again, I’m not looking for actual code here but more of a ‘how it works’ and ‘where does the code go’. Is what I typed above correct?

Thanks again for hanging in with me! I appreciate your time.

No worries. I’ve been cranky the past couple of days. :slight_smile:

Sounds right, to me. One thing that bites some people is that DataAvailable may not be complete when the event fires. It’s helpful if your server has a terminator at the end of its OK command so you can tell if it’s complete. Probably not a big deal with such a small amount of data but with longer responses this can be a big deal. In your testing you’ll have to see if this comes into play.

Good luck and check back in if you run into problems.

I wonder if you may be adding a layer of protocol that isn’t necessary. The TCP protocol automatically takes care of handshaking and data buffering. So you may not need to add your own “Send me data” signals on top of that.

Yes. That’s called a State Machine. It’s the correct approach for this kind of communication.

It absolutely is necessary.

[quote=267942:@Tim Hare]
It absolutely is necessary.[/quote]
I guess I’ll have to go back and check my last TCP project. I don’t recall having to make my main program tell the main program at the remote end to stop sending because the buffer is full.

No, you don’t need to add protocol at that level, but you certainly need to impose protocol at a higher level. Perhaps I misunderstood your statement.

Perhaps you should write the data with a ‘boundary’
more like :test123 and filter it out (with nthfield countfield ,)

test123hellotest123

if bigger than 2 the dataavailable event has given more than 1 line…

Goodluck

The reason why I made my previous comments is that sending a line of data, then waiting for an ‘ok’ to come back before sending the next line sounds very much like low level handshaking to me, something that the TCP protocol can do all by itself, unless there is something else going on that we don’t know about. So perhaps I should have asked the significance of the ‘ok’ reply. Is it just used to allow the server time to process the current data? Is there ever a situation where the server replies with some other text string? Is there a situation where the server never replies at all? If so, how should the client respond?

There’s a lot that can happen on the other end that the simple TCP protocol can’t help you with. It’s always good to know that the program on the other end of the line is awake, responsive and processing your data, rather than just shoving data at the remote and hoping it was in the expected form and was actually acted upon. One example is a simple file transfer. What happens if the file cannot be saved on the remote end for any of a number of reasons? You’d want to know about it so you don’t consider that file “done”. And really, the more verbose the exchange is, the more resilient it can be.

A real-life example is the SMTP protocol, which is built on top of TCP/IP. It’s very verbose, which is why it is so succussful.