🚀 go-pugleaf

Gambit,
As always, thank you for your prompt replies.  I need to state some
information about the clients.  These are a number of different devices that
are _not_ network aware.  They use proprietary serial protocols over IR or
RS-232.  To meet the demands of modern connectivity, the RS-232 and IR
(converted to RS-232) is fed into a device server (Lantronix CoBox) for
Ethernet network connections.  These are lecgacy devices and there is no way
to add things to the datastream such as telling the server how much data to
expect.  Instead, there are data start and end flags that must be detected
by the server.  My approach has been to capture the data into a disk file,
which is then processed "offline".  I really don't have any other option
than to capture an unknown amount of binary data.  Yes, these are the joys
of device communications that were not designed with sophisticated protocols
in mind.  As a great testament to INDY (and Winshoes), the algorithm
described below has worked very well for several years.  It's just that
Windows XP seems to be more sesitive to the TIME_WAIT issue and I need to
address this as soon as possible.

Paul Mac

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:41703c92$1@newsgroups.borland.com...
>
> "Paul Machiaverna" <paul.machiaverna@i-stat.com> wrote in message
> news:4170363b$1@newsgroups.borland.com...
>
> > I'm using INDY 9 in a server application and would like to know the
> preferred method of reading binary data from a client.
>
> That depends on how the client is sending the data exactly, but typically
> you should use the ReadBuffer() or ReadStream() method.
>
> > I've been using this code (in the OnExecute method):
>
> I would not recommend that approach.  A better approach would be for the
> client to send the size of the data before the data itself.  Then your
> server can read the size first and know how many remaining bytes to read
> afterwards.  Then you don't need to use Readable() and CurrentReadBuffer()
> at all.
>
> > ProcessData feeds each byte through a state machine to determine the end
> of data marker.
>
> That is also not a good approach.  If the client sends the data size, then
> you will know exactly how many bytes belong to each record.  Then you
don't
> need end markers at all, although you could still use them if you want to
> validate the data integrity, at least
>
>
> Gambit
>
>