Trasmitting binary files working but not quite.
by Scott Burns · in Torque Game Engine · 05/26/2006 (12:23 pm) · 9 replies
Ok, here's one for those of you who are the more netcode savy.
I'm working on this project where I have to transmit a binary file to a non-Torque program while in-game. I've gotten this to work somewhat. I found this resource for trasmitting binary files, www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=6520. I added it in and send the file to the computer running the non-Torque program and nothing happens right away. Then I quit the Torque app and all of a sudden the non-Torque app recieves the file and everything looks as it should.
So basically I'm trying to figure out what exactly is causing the file to not completely transfer until I exit Torque. Anybody have any ideas as to what could be causing this?
I'm working on this project where I have to transmit a binary file to a non-Torque program while in-game. I've gotten this to work somewhat. I found this resource for trasmitting binary files, www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=6520. I added it in and send the file to the computer running the non-Torque program and nothing happens right away. Then I quit the Torque app and all of a sudden the non-Torque app recieves the file and everything looks as it should.
So basically I'm trying to figure out what exactly is causing the file to not completely transfer until I exit Torque. Anybody have any ideas as to what could be causing this?
#2
What appears to be occuring here is that you aren't filling up enough packets for the pipe to actually deliver, so it's caching, waiting for more. When you shutdown Torque, it in turn shuts down the socket, and part of that is a flush send.
05/26/2006 (12:46 pm)
Yes, this sounds as if the resource isn't flushing the pipeline when it thinks it's finished sending (normal operations actually, if/when you have a continuous stream).What appears to be occuring here is that you aren't filling up enough packets for the pipe to actually deliver, so it's caching, waiting for more. When you shutdown Torque, it in turn shuts down the socket, and part of that is a flush send.
#3
05/26/2006 (1:19 pm)
Ok, so I should be able to just manually flush the pipeline force it to send then. How would I go about doing that?
#4
I keep getting the feeling that I'm overlooking something important and the answer is right there in front of me, but I've sifted through the code and all documentation, including MSDN, and still haven't found what is needed. Granted one of my technical weaknesses has always been netcode, so this probably isn't as hard as it seems to me. I need to get this done in the next couple days, so if anybody knows how to force this send I'd appreciate the help.
05/30/2006 (7:50 am)
Well, after a particularly long debug session of stepping through the shutdown process I'm not much closer to finding how to force this send. While I was stepping through it all I got it down to a single line where the send happens, unfortunately that was a delete command.I keep getting the feeling that I'm overlooking something important and the answer is right there in front of me, but I've sifted through the code and all documentation, including MSDN, and still haven't found what is needed. Granted one of my technical weaknesses has always been netcode, so this probably isn't as hard as it seems to me. I need to get this done in the next couple days, so if anybody knows how to force this send I'd appreciate the help.
#5
Like Stephen said the flush send is part of shutting down the socket and that flush send is what I've been trying to figure out how to do. So I figure there's no reason I can't disconnect the socket and get that flush send. So after I send the file I disconnect the socket and it forces the file out sends it like it should. Not the most elegant solution but it will work for now.
Thanks for the help Stephen and Paul.
05/30/2006 (8:39 am)
Well I think I may have found a workable solution for the time being.Like Stephen said the flush send is part of shutting down the socket and that flush send is what I've been trying to figure out how to do. So I figure there's no reason I can't disconnect the socket and get that flush send. So after I send the file I disconnect the socket and it forces the file out sends it like it should. Not the most elegant solution but it will work for now.
Thanks for the help Stephen and Paul.
#6
05/30/2006 (8:40 am)
Show us your code for the other end.
#7
05/30/2006 (8:43 am)
Sorry, I don't have the code for the app on the other end. I wouldn't be able to post it if I did anyway.
#8
Also note that since the underlying implementation is platform specific, you'll want to pay careful attention to the (possibly) different implementation requirements for linux, mac, etc.
Final note: flush is an expressly designed concept for generic streams that is useful for when you do not want to shut down the stream itself, but do need to force delivery of content in the stream that may be currently buffered sender side. Flush is always called as part of the stream shutdown process, but sometimes (perfect example is this case you are having) you want the ability to force a flush. It's most commonly used with file i/o, but it appears that the implementation in the resource is causing a need for it here as well.
05/31/2006 (11:47 am)
I looked briefly at the resource, and it appears that it didn't implement a ->flush() capability. I'd suggest that you look at the FileStream->flush() command's implementation, and re-implement it for your new stream type as well, and then use that stream.Also note that since the underlying implementation is platform specific, you'll want to pay careful attention to the (possibly) different implementation requirements for linux, mac, etc.
Final note: flush is an expressly designed concept for generic streams that is useful for when you do not want to shut down the stream itself, but do need to force delivery of content in the stream that may be currently buffered sender side. Flush is always called as part of the stream shutdown process, but sometimes (perfect example is this case you are having) you want the ability to force a flush. It's most commonly used with file i/o, but it appears that the implementation in the resource is causing a need for it here as well.
#9
06/06/2006 (11:43 am)
Thanks Stephen, that should help a lot. I've been sticking with the disconnect method for now since I've been short on time and its not necessary for me to maintain the connections after they've done their job. The app I'm working with shuts down the connections once something is transmitted anyway, but I know I'll be needing to do this in the future for other projects. 
Torque Owner Paul Griffiths