Hi Robert,
Just for the record everything works fine.
Thanks for your feedback.
simply check the byte count returned by ReceiveStr. It works great.
Just a quick note: Receive() is better than ReceiveStr() unless your
protocol is text and line oriented.
Look at the source of ReceiveStr()
Hello Wilfried,
Just for the record everything works fine. Hopefully someone else can benefit
from my little journey here. I no longer check RcvdCount and simply check the
byte count returned by ReceiveStr. It works great.
This is a relief because ICS is my preferred choice for socket work.
Hello Wilfried,
Well now I know the problem. The Overbyte web site says RcvdCount is
unreliable. Their example shows the use of a 8192 size buffer in Data
Available to receive whatever data may be there and to check the return of the
Receive() call to know how much data was delivered. I ass
Hello again Wilfried,
A little extra data. My Data Available event handler grabs the number of
waiting bytes in the queue from the RcvdCount property (I use it to size the
receive buffer). If the byte count is 0, I just ignore the Data Available
event. That is, I do nothing. I just added c
Hello Wilfried,
Thank you for your reply.
It appears to be something with my application but I don't know what. I
grabbed your SocketSpy program and set it up to act as a proxy between the
streaming image server and my program. Your log kept accumulating incoming
data from the server while
Maybe you should create an exception handler by assigning OnBgException event -
unhandled excepion is the frequent reason of strange behaviors in async
applications. You can also indeed sniff the data transferred - I recommend
SmSniff, which is as simple as it could be.
--
Anton
--
To unsubscr
Hello Robert,
To be absolutely sure if it is the sending or receiving application I
suggest you put SocketSpy between it. You find it on user made page.
Then we are sure in wich application is a bug and we can search deeper.
---
Rgds, Wilfried [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics
