I have a EASYTCPSOCKET which I am sending a file out from it. This is the code
Dim ReadStream As BinaryStream = BinaryStream.Open(readFile, False)
ReadStream.LittleEndian = True
’ if file exists etc…
Do Until ReadStream.EOF
app.YieldToNextThread
SendMessage(1,EncodeBase64(ReadStream.Read(1024*1000)))
app.DoEvents(100) ' be nice to xojo
Loop
ReadStream.Close
ReadStream=Nil
purge
This is being done in the received event of the EASYTCP socket.
If I send a 9 mbytes of data, the Xojo EXE uses 75 MB of memory and never releases it until the socket is closed. (even base64 should only treble it)
I need the socket open all the time so the client can get updates.
*Note its not held in memory waiting to be sent, the file arrives the other end fine, and still the memory is not released.
Hi Dave,
this is a known issue at least for me on Windows platform.
For example in a WebApplication if you create a big webfile the memory used to send its contents it’s never released until the session closes: in this case I’m supposing that when session closes all the sockets for that session are closed.
Please file a bug report with your example.
without going deeper into this issue: To me your AppYieldTo Next Thread and DoEvents look kinda strange… do you run this as a service, within a thread or within a desktop app?
[quote=158679:@dave duke]If I send a 9 mbytes of data, the Xojo EXE uses 75 MB of memory and never releases it until the socket is closed. (even base64 should only treble it)
I need the socket open all the time so the client can get updates.[/quote]
I just added some notes to your case. From what I can see, the big problem is that the Flush method appears to hang when using EasyTCP sockets for some reason.
Dave I have successfully sent files > 10Gb over crappy NZ DSL (upload speed 600K). Not using EasyTCPSocket or flush, but with an event driven model. In fact I found using 6 TCPSockets with 256k of data per concurrent send gave the best results. I achieved this by sending an xml string terminated by an end of file marker (CharB(26)) followed by the raw data. The Xml file included a file offset position for that block, a checksum for that block & the length of the block. The server would respond with a good or bad depending on the checksum match whereupon the client would either resend the corrupt block or send a new block.
Of course this was before JSON was available in Real Studio, so maybe my solution no longer works.
But I’d be happy to discuss/help you work through the issue privately.