Indy question
Quick question: I'm converting a program from TClientSocket/TServerSocke
1. Does it include buffering? I need to send 100s of K on startup and I need to manually buffer it with TClientSocket, so do I need do the same with Indy?
2. Socket messages are not delimited, ie I need to use STX/ETX type of protocol. Do I need do that in Indy?
3. Are Indy messages generally guaranteed to arrive, barring network failure? And in the same sequence as sent?
Preferably a Yes/No to those questions rather than a "read this link" please!
Cheers
Geoff M.
1. Does it include buffering? I need to send 100s of K on startup and I need to manually buffer it with TClientSocket, so do I need do the same with Indy?
2. Socket messages are not delimited, ie I need to use STX/ETX type of protocol. Do I need do that in Indy?
3. Are Indy messages generally guaranteed to arrive, barring network failure? And in the same sequence as sent?
Preferably a Yes/No to those questions rather than a "read this link" please!
Cheers
Geoff M.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Geoff,
Regarding (2)
Many people make assumptions as to the 1 send = 1 read, because it "seems" to work (which it usually does when sending small packets of data). This can be a fatal application flaw if coded based on this assumtion, because it is just PLAIN WRONG. The underlying transport makes no warranty as to where/if/how the data will be split; the only guarantee it makes (regarding transport) is that if the result of the api is success, the data will have been delivered.
I found this out the hard way quite a few years back... ;-)
Regards,
Russell
Regarding (2)
Many people make assumptions as to the 1 send = 1 read, because it "seems" to work (which it usually does when sending small packets of data). This can be a fatal application flaw if coded based on this assumtion, because it is just PLAIN WRONG. The underlying transport makes no warranty as to where/if/how the data will be split; the only guarantee it makes (regarding transport) is that if the result of the api is success, the data will have been delivered.
I found this out the hard way quite a few years back... ;-)
Regards,
Russell
ASKER
Tell me about it! I've always been telling people to *expect* split packets but thought maybe I was wrong after reading some posts on EE. Thanks.
ASKER
#2 surprises me a little, from what I've read on EE. Several times people have said that you get whole messages in one block. I assume that they are wrong. I had to prove to one of my programmers that this was the case with serial ports (who has since found an alternative career, to put it politely), so it wouldn't surprise me that others assume the same.
Thanks
Geoff M.