Hello all,
I am completely new to IP programming, and I am stumped on the following scenario:
I want to send 1 ASCII string - to my TV, actually - then read its (1 packet) ASCII string response. [All "strings" are printable and less than 100 characters.]
Problem is, the messages don't use either a length attribute or an end-of-line character(s). (The data is equivalent to COM port traffic, which does use a CR.)
I have looked at some Indy code examples, but I am unclear as to which class & method I should be using. (Not Writeln() & ReadLn() methinks.)
But I don't know if this library is preferable for my needs.
I have captured a simple example using a freeware app and Wireshark, if that helps anyone. But really I'm just after a small code snippet if that is possible.
Regards - Kane.
Vote for best question.
Score: 0
# Vote: 0
Date Posted: 12-Jul-2014, at 4:18 AM EST
From: Anonymous
Re: Simple code to write 1 then read 1 ASCII TCP packet?
Kane wrote:
> So, "00QAP' (Query Appliance) is the command [the "00" is a constant],
> and the model name is the response. As you can see, all printable
> ASCII. The manual says some messages might be bracketed with
> STX & ETX (0x02 & 0x03 bytes), but my tests show these aren't required
> (probably intended for COM port traffic anyhow).
There are TCP protocols that use STX/ETX, and that would be easy to handle
with Indy. But looking at your Wireshark capture, STX/ETX is not present,
so I will ignore that.
Based on this capture, all I have to go on is the assumption that specific
packets have specific byte lengths, indicated by the name string at the front
of each packet. Can you provide a capture that shows multiple commands/responses
going back and forth on the same TCP connection?
> To address the stream vs. message aspect, all responses are of fixed &
> known length (true for commands also)
Well, there you go then, and I mentioned that possibility in my very first
reply in this discussion:
{quote}
If there is no length attribute or end-of-message terminator, the only option
left is if the messages themselves are fixed-length. Either all of the messages
are the same length, or specific types of messages have specific lengths,
and you would have to infer the length based on the message type.
{quote}
> provided the 3-letter command echo is first read. But the Packet Sender
> app, which I am using as a client, works without knowing this info. Maybe
> it uses a short Read timeout, or there is a flag in the packet which signifies
> this (you can tell I am a newbie). But reading 1 packet is probably sufficient
> for all cases.
Do *all* of the replies have a 3-letter code in front of them? If so, then
you simply tell Indy to read a 3-byte string via TIdIOHandler.ReadString(3),
then read however many remaining bytes belong to that code (in your capture,
that would be 20 for the 'QAP' reply).
--
Remy Lebeau (TeamB)
Vote for best answer.
Score: 0
# Vote: 0
Date Posted: 16-Jul-2014, at 6:24 PM EST
From: Remy Lebeau (TeamB)
Re: Simple code to write 1 then read 1 ASCII TCP packet?
I have uploaded a sample I/O command here: http://s000.tinyupload.com/?file_id=60714632643083282905
So, "00QAP' (Query Appliance) is the command [the "00" is a constant], and the model name is the response. As you can see, all printable ASCII. The manual says some messages might be bracketed with STX & ETX (0x02 & 0x03 bytes), but my tests show these aren't required (probably intended for COM port traffic anyhow).
To address the stream vs. message aspect, all responses are of fixed & known length (true for commands also), provided the 3-letter command echo is first read. But the Packet Sender app, which I am using as a client, works without knowing this info. Maybe it uses a short Read timeout, or there is a flag in the packet which signifies this (you can tell I am a newbie). But reading 1 packet is probably sufficient for all cases.
So I am hoping that, rather than posting code, someone can suggest appropriate methods and properties which I can use as a proper starting point.
Vote for best answer.
Score: 0
# Vote: 0
Date Posted: 15-Jul-2014, at 10:08 PM EST
From: Anonymous
Re: Simple code to write 1 then read 1 ASCII TCP packet?
Kane wrote:
> I want to send 1 ASCII string - to my TV, actually - then read its (1
> packet) ASCII string response. [All "strings" are printable and less
> than 100 characters.]
> Problem is, the messages don't use either a length attribute or an
> end-of-line character(s).
There has to be something. TCP is stream-oriented, not message-oriented.
Even the TV has to know where one message ends and the next begins. If
there is no length attribute or end-of-message terminator, the only option
left is if the messages themselves are fixed-length. Either all of the messages
are the same length, or specific types of messages have specific lengths,
and you would have to infer the length based on the message type.
> The data is equivalent to COM port traffic, which does use a CR.
That is optional on a COM port.
> I have looked at some Indy code examples, but I am unclear as to which
> class & method I should be using.
That is difficult to answer without knowing the exact protocol being used.
There are many different possibilities.
> But I don't know if this library is preferable for my needs.
It will work fine, as will any other TCP library. The issue is not which
library to use, but in how you use it. And you need to know the protocol
in order to know how to use it.
> I have captured a simple example using a freeware app and Wireshark,
> if that helps anyone.
Yes, please post that.
> But really I'm just after a small code snippet if that is possible.
Not without knowing what kind of data in involved.
--
Remy Lebeau (TeamB)
Vote for best answer.
Score: 0
# Vote: 0
Date Posted: 14-Jul-2014, at 11:03 AM EST
From: Remy Lebeau (TeamB)
Re: Simple code to write 1 then read 1 ASCII TCP packet?
Kane wrote:
> I want to send 1 ASCII string - to my TV, actually - then read its (1
> packet) ASCII string response. [All "strings" are printable and less
> than 100 characters.]
> Problem is, the messages don't use either a length attribute or an
> end-of-line character(s).
There has to be something. TCP is stream-oriented, not message-oriented.
Even the TV has to know where one message ends and the next begins. If
there is no length attribute or end-of-message terminator, the only option
left is if the messages themselves are fixed-length. Either all of the messages
are the same length, or specific types of messages have specific lengths,
and you would have to infer the length based on the message type.
> The data is equivalent to COM port traffic, which does use a CR.
That is optional on a COM port.
> I have looked at some Indy code examples, but I am unclear as to which
> class & method I should be using.
That is difficult to answer without knowing the exact protocol being used.
There are many different possibilities.
> But I don't know if this library is preferable for my needs.
It will work fine, as will any other TCP library. The issue is not which
library to use, but in how you use it. And you need to know the protocol
in order to know how to use it.
> I have captured a simple example using a freeware app and Wireshark,
> if that helps anyone.
Yes, please post that.
> But really I'm just after a small code snippet if that is possible.
Not without knowing what kind of data in involved.
--
Remy Lebeau (TeamB)
Mega Search
Sign Up 
