Tcp Client

 
#1

Hello,

I try to link to EZ-Builder from my TCP/IP client via Windows socket. Can anybody explain the protocol of communication at the server side? I can successfully connect from both my program and Telnet PuTTY, but calling EZ-Script functions encounters troubles. Using PuTTY, I could generate speech from string with Say( text to speech ), but Print( txt ) outputs nothing. Bare TCP/IP produces no reaction at all. I can send strings and the main question is how to mark their end. I can use null-terminated strings. Does anybody know how the receiving server is implemented?

#2

There's an example in the EZ-SDK package for sending ezscript commands via the tcp server of EZ-Builder.

Commands for the tcpcommand console are terminated with a new line.

I need further explanation of these two statements:

- What is a null-terminated string to a tcp command line console?

- What is a "bare tcp/ip"?

#3

I have only used it with a Tasker plugin called Send/Expect which emulates a Telnet client. I needed to terminate commands with \n to make it work. \n I believe is Send/Expect nomenclature for "new line"

Alan

#4

An update to the previous post.

PuTTY client has 'Raw TCP' mode too. I tried and it works like Telnet. That is the only difference possible with my program is formatting of strings which I send over TCP.

Null-terminated means that null character is added after \n. The reason is that Internet may break long strings into parts and the server needs to know whether it received all that was sent.
I added \r\n which stands for Caret return, New line.
This is from EZ-B SDK Windows Tutorial 52 Form1.cs: "The string is terminated with a \r\n"

#5

Okay - I can help with your misunderstanding of tcp and command line console ui

The "internet" doesn't break up packets, routers do. And the only protocol which would require your application to programmatically assemble received packets into your applications specific packet is if you're using UDP. However, even if you're using UDP, terminating a string with a null character doesn't make a difference unless the application requires it.

There's an OSI network model that you should google to understand the separation of transmission layers. Discussing tcp or UDP in the same conversation as the application protocol is not applicable. It's like discussing how fast you're car is going and how big the trunk is at the same time. They're two separate topics.

There's no need to discuss how tcp works for this thread, however it may benefit you to google a bit because you seem interested in it.

The tcp protocol is transmission controlled. This means the tcp stack takes care of assembling and sorting the incoming packets for you.

The ezbuilder tcp server is a command line console. It accepts a single line of text terminated by a new line (crlf). This means putting putty in regular terminal ascii terminal mode will work just fine.

For code example, use the EZ-SDK package.

#6

Bare TCP means that I don't use Telnet client. Just send strings through the socket.

#7

sending strings through a socket is all that Telnet does. You can use a Telnet client to test any TCP Socket app. It is the simplest of TCP clients.

Alan

#8

DJ Sures,

So your suggestion is that I should get rid of that null at the end and consider that each received string will exactly correspond to the sent one?

#9

get rid of the null - and look at the example in the EZ-SDK package please. To repeat, the string in a command line console is terminated with a new line (CRLF).

#10

Yes, CRLF is already the marker. No need to duplicate it. Thank you.