I have a subclassed TCPSocket and it works well however there are times where I notice some of the datachunks arrive late (I assume) and part of the command that I write to the socket doesn’t receive all of the info. I have seen other posts with responses explaining how TCPSockets.DataAvailable works. tcpsocket write packet length
My question is what type of “double checking” do you provide to ensure that you are dealing with all of your data chunks even for those that may come in later? Are there best practice recommendations to use TCPSOCKET.SendProgress and/or TCPSOCKET.SendComplete to accomplish this?
This is a snippet of my Method that calls the poll and the subclassed TCPSOCKET.
Do
Command_Collector_Socket1.poll // (Synchronous Mode)
Loop Until (Command_Collector_Socket1.IsConnected) or (Microseconds - StartTimer > kTimeOut)
Sub Connected ()
//Send Username
me.Flush
me.Write login_username + chr(13)+chr(10)
me.Flush
//Send Password
me.Flush
me.Write login_password +chr(13)+chr(10)
me.Flush
end Sub
Sub DataAvailable()
do
ReceivedBuffer = ReceivedBuffer + me.ReadAll
loop until me.BytesAvailable = 0
end Sub
If the chunks are delimited by a specific character or string of characters, you can check the read buffer for those markers and only extract whole chunks from the buffer. This allows incomplete chunks to stay in the buffer until completed.
[code]
’ untested forum code
Sub DataAvailable()
Dim chunkboundary As Integer = Instr(Me.LookAhead, chr(13)+chr(10)) ’ assuming chr(13)+chr(10) is the delimiter
Do Until chunkboundary = 0
ReceivedBuffer = Me.Read(ChunkBoundary) ’ read one chunk, removing it from the buffer
chunkboundary = Instr(Me.LookAhead, chr(13)+chr(10)) ’ grab the next chunk
Loop
end Sub[/code]
I always add a timer & poll the socket while it’s connected. The last little bits of data always seem to take too long to fire the dataavailable event.
Thanks Guys. I saw a few examples per your recommendation Wayne and thank you, I will play with this type of code.
//read a byte at a time for 10 seconds
st = Microseconds
while s.IsConnected
s.Poll
if s.BytesAvailable > 0 then
TextArea1.AppendText s.Read(1)
TextArea1.Refresh
end if
if (Microseconds - st) > (10000 * 1000) then
s.Disconnect
end if
wend
I tried to stay away from polling and did as Andrew said - accumulate the data in a buffer and when I would get “whole chunks” then deal with them.
Wrote an entire db driver in pure RB/Xojo code nearly 6 years ago and to this day it still just works.
Its all subclassed TCP sockets with the events implemented.
Thanks again Guys. Norman could you share some of that Async sample code without using polling (sync)? I am not sure how my code would flow async wise with TELNET.
I basically do the same thing Andrew described when I write HL7 interfaces. A valid message is wrapped between control characters and if I don’t see those at the beginning and ending of the message, then I know it’s either an incomplete broken message or that the entire message hasn’t arrived yet.
Thanks Ken! In my case my devices are very slow to respond in the case of higher latent network links (ie. a bandwidth saturated T1).
I have trying to receive the buffer like you and Andrew suggested succesfully now. I have seen a ton of posts on the forum that talk about never using “Poll” if they can help it. I am still trying to understand why since as I understand using TCPSOCKET.POLL is the way to use it synchronous vs. asynchronous. I haven’t been able to see “how” to do it async anywhere, but I see people saying to stay away from poll
You probably don’t see any async examples because each case is so unique and the code is spread across several places, so it’s difficult to present it in a unified manner on a forum. The way it works is you create a state machine. Each time DataAvailable fires, you ask the questions
What am I expecting?
Did I get it?
Did I get part of it?
Did I get something different?
And you respond appropriately. If you control both ends, you define your own protocol of request/response pairs. Otherwise, you respond to somebody else’s protocol. But at every point, there’s a clearly defined next step, even if the next step is to simply wait for something else to happen.
