TCPSocket confusion

I have the following code in the send complete event handler of a TCPSocket of a file sending utility I’m working on.
The problem is, it doesn’t appear to send to the info to the server UNLESS I uncomment and allow the message box to open.
Is there a way to make this work without the message box?

[quote]if isSending then //isSending is a variable local to the window
isSending = False
TCPSocket1(mCurrentSocket-1).Write(“123”)
'MsgBox “Success!”
end if[/quote]

[quote=54024:@Joseph Morgan]I have the following code in the send complete event handler of a TCPSocket of a file sending utility I’m working on.
The problem is, it doesn’t appear to send to the info to the server UNLESS I uncomment and allow the message box to open.
Is there a way to make this work without the message box?[/quote]

Try Polling or Flushing the socket

Thank you for the suggestion. I just tried flushing and polling before or after sending as well as both. Is there something else that msg box is doing behind scenes that another method will do that is less noticeable?

running an event loop which is why I’d expect polling to work
You might need to poll it repeatedly until it reports data is all sent
Along the lines of

while TCPSocket1(mCurrentSocket).BytesLeftToSend > 0
TCPSocket1(mCurrentSocket).Poll
wend

but this polls it VERY rapidly which isn;t necessary and you could probably sleep the current thread for a few msec

Hi Norman, I have tried that as you suggested. I put the while loop in the SendComplete handler. Is that where you suggest placing it? I also used app.sleepcurrentthread(100) in the line right after polling. (never used it before so again not sure where to place it).

I missed that you’d stuck the additional send in the send complete handler
Basically that will, when it figures out that the data has all been sent, send one more chunk (“123”), when that sends it will send one more chunk (“123”), and so on
I’m surprised it ever finished or that the dialog ever went away
Don’t write more data in SendComplete unless you have a way to eventually decide to NOT write that data or you run the risk of getting stuck in that event

That’s probably why the msgbox makes things work
It stops the flow of events from continuing

Actually I am using a way to decide NOT to write the data and get stuck: the ifSending boolean is set to True when we select the file and set to False immediately before writing “123”. Inserting a break point inside of the if statement only trips once (after the file is selected and sent)

if isSending then //isSending is a variable local to the window isSending = False TCPSocket1(mCurrentSocket-1).Write("123") 'MsgBox "Success!" end if

Make sure you’re polling the right socket. Norman’s code needs to be adjusted. Are you writing to the same socket or a different one?

Hi Tim,

Yes I am polling the correct socket “TCPSocket1(mCurrentSocket-1)” was the socket I am using and to simplify I changed to TCPSocket1 (got rid of the set to simplify). Here’s the current code that still isn’t working:

[code] if isSending then
isSending = False

while TCPSocket1.BytesLeftToSend > 0
  TCPSocket1.poll
  app.SleepCurrentThread(1500)
wend

TCPSocket1.Write("123")
AddMessage("Socket " + " send complete!!!")///<< left overs from the example projects
'MsgBox "Success"

end if[/code]

I found that writing something to the socket just before running the poll loop causes it to work but only for smaller files <3mb… And adjusting the sleep thread time helps to allow for slightly larger files up to 14mb but testing a 90mb file fails. Not sure why any of this is happening.

Make sure you poll after you add the “123” to the socket too

Esp if the socket then happens to go out of scope & closes asap

We use TCP Sockets for a LOT of things and large files work without a hassle as long as you remember to not dispose of the socket before its done

Going out of scope is the most likely explanation. How is the socket created? Is it on a window? Does the window get closed after the socket finishes? You shouldn’t need to poll the socket at all, of course, so we’re just masking the real issue.

I have now tried running the poll both before and after at the same time when sending “123” to the socket but I’m still experiencing inconsistent results as it applies to file sizes. Larger files still fail while smaller files work.

The socket is dragged into the window. I never close the window or close the socket. I do close the binary file but I don’t think that would be related. I would think polling would not be needed either but if thats what would make it work I’d be happy with it. Lol

Are you writing “123” to the same socket that just finished sending the file? Or a different socket? If it’s the same one, then

a) refer to it as “me” instead of by name.
b) try sending “123” at the same time that you send the file.

TCPSocket1.Write theFileData
TCPSocket1.Write “123”

The data stream will be the same.

I’ll confess I’m a bit baffled by how this is set up and what the issue is without seeing actual code.
We use the TCPSocket in the remote debugger stub & I can say I’ve used that with some very large files.
And we use it elsewhere with some enormous files - GB’s in size.

Norman I know you’re right so I’m sure I’m doing something wrong. And I think we are getting closer to finding the problem.

Tim’s suggestion about keeping it all in the same data stream had me curious so without changing any code on the client I ran a test on the server. I wrote the incoming data on the server to a text area and my “123” is occasionally (depending on file size) tagging along with the file data and is the last three characters in the text area on the failed sends. This is happening on server side because I am doing a ReadAll in the DataAvailable event.

The reason “123” is being sent is to tell the server that the file data is completely sent so I can save it back to a file on server. Is there a best practice for alerting the server that the file is completely sent? I suppose I could check if the ReadAll CONTAINS the “123” or perhaps something more creative/unique than “123”

If you want to go really old school, use the End Of Transmission control character, &u4.

Thank you Norman, Tim & Andrew for the suggestions.

“&u4” should work as being sent as part of the data sent.

Bit, It looks like the socket sends “&u4” behind the scenes as part of the client initializing the file send. So I modified the client to send “&u4123” to indicate file send completion. Now it appears to work but is kind of slow and I think its the “if s.CountFields(”&u4123") > 1" that is slowing it down. Do you guys think there is a way to speed this up somehow?

On the server I changed the DataAvailable event on server side to show the following:

//Server DataAvailable

[code]
Dim s as String = Self.ReadAll

mIncomingData = mIncomingData + s

if s.CountFields("&u4123") > 1 Then

mIncomingData = mIncomingData + s.Leftb(s.Lenb-3)

Dim f As FolderItem
Dim bs As BinaryStream

//get a folderitem
f = GetFolderItem("Test1")

//create a binary file with the type of text (defined in the file types dialog)
bs = BinaryStream.Create(f, True)

//check to see if it was created
If bs <> Nil Then
  //write the contents of the editField
  
  bs.Write(mIncomingData)
  
  //close the binaryStream
  bs.Close
  
  'MsgBox  "WORKCOMPLETE" 
  
End If

end if[/code]

//Push button on client side

[code]
Sub Action()

Dim f As FolderItem

//get a folderitem
f = GetOpenFolderItem("")

mIsSending = True

//make sure it exists before we try to read it
If f<>nil Then

if f.Exists then
  //open the folderitem as a binary file without write privelages
  //     To open with write privelages, use true instead of false
  bs = BinaryStream.Open(f, False)
  
  //make sure we have a binary stream to read from
  If bs <> Nil Then
    //read the whole binaryStream
    fileSize = bs.Length
    TCPSocket1.Write(bs.Read(bs.Length))
    //close the binaryStream
    bs.Close
  End If
End If

end if
End Sub[/code]

//SendComplete on Client Side

[code]Sub SendComplete(userAborted as Boolean)
#Pragma Unused userAborted

if mIsSending then
me.Write("&u4123")
me.Flush
mIsSending = False
end if

End Sub[/code]

[quote=54152:@Joseph Morgan]
The reason “123” is being sent is to tell the server that the file data is completely sent so I can save it back to a file on server. Is there a best practice for alerting the server that the file is completely sent? I suppose I could check if the ReadAll CONTAINS the “123” or perhaps something more creative/unique than “123”[/quote]

123 could occur in the data being sent
You might send the size first then you know exactly how many bytes to expect to read

+1 to Norman’s suggestion. You need a more robust protocol. The receiving end needs to know what to expect. Number of bytes, etc.

I will do as you suggest and add more to the protocol. I would have never gotten far enough to improve my protocol without your help since I never thought sending a command such as “123” might get mixed in with the other data. I thought writing a command would come through separately and thats what I was hung up on. Now that I have actually seen it send files (of any size) I can go in and back fill all the protocol I need.

Thanks again for setting me straight! :slight_smile: