SendNetworkFile still buggy or can i use it safely?

[Anden]

Of course. Test for 1, 2, 3 or 4? (i'd really like to minimize complexity)

1 needs special network setup to force errors (= complex)
2 needs "the right code" (close immediately after send) and a slow client to max chances of occurrence
3 needs documentation
4 is easy to test

[Trond]

If it only happens on a special network under extremely strict conditions and under the supervision of networking experts waged at 125 euro per hour, will it happen for your client?

[Jan Vooijs]

Facts are:
1)
If there are network problems (failure in transmissions, retransmissions necessary, aso ...) ReceiveNetworkFile() never returns from it's task and the PB app "hangs" with 100% CPU load (a ping command terminates with a timeout in the same situation btw)

2)
If one closes the connection immediately after SendNetworkFile() returns, it could happen, that a network "broadcast" is triggered (=loads of small packets at the receiving client queue = 100% cpu load again).
This is only the case, if ReceiveNetworkFile() on the client side has NOT fully received the file at that time.
Which can happen sometimes (seems to be more frequent on slower client machines), because it seems that Send/ReceiveNetworkFile use some kind of caching algo (i have to guess here again, i don't know your code and you don't tell us. Thus that's all the help i can give you right now).

3)
The missing progress information is obvious and would help a lot in nailing down or avoiding the problems described above.

For the numbers 1 and 2 this is NOT a 100% PB problem i had (have) the same problems with an old version of PowerBasic (7.04 to be precise, never upgraded since i use PB exclusively now). And also a version of RealBasic has the same problem (but you can 'interrupt' the call in a way by a maximum time to wait). I think it is more a windows problem than a PB problem. Or the implementation of a win xp dll (which one i never found out) which has the problem. But giving the call a max time to wait helps enormously like some implementations use (RapidQ for instance, and yes PowerBasic [in the open statement]).

Number 3, a progress report is not possible i believe PowerBasic has the same problem (never returns on 'no completion' of a recieve) and yes it goes to 100% then (hit the reset--) also.

Jan V.

[Anden]

If it only happens on a special network under extremely strict conditions and under the supervision of networking experts waged at 125 euro per hour, will it happen for your client?

It will, because the "special conditions" (it's just a hefty network load) are only necessary to increase/force errors. It just happens less often if you don't force it.

It's part of the bug fixing process to raise certain error conditions, you know ...

[netmaestro]

I don't believe SendNetworkFile() was ever intended for large file transfers. I don't need anything that'll transfer files larger than a couple of mb over a network at the moment, but if I did I wouldn't use SendNetworkFile(). I'd take an MD5 fingerprint of the file, read it in in chunks of 100k, send them one at a time and when they are gone I'd send the fingerprint. The whole thing would go in its own thread and with this approach, health-monitoring as well as a progress bar are a snap. And your main loop can just keep on truckin'. Process is reversed on the receiving end and when the whole file is in its md5 fingerprint gets checked against the one it received and if they match you can display a messagebox with confidence: File received successfully. If you do it this way you can send gig-sized files across the network, cancel anytime, watch the progress, etc. Might take a couple hours to program it but the result would be worth the effort, imho.

Another advantage to this approach is that you can manipulate the transfer speed. If time isn't a concern you can put sizable delays in the loops and avoid bogging the network traffic down. Take a little care in the design and you can even do pause-stop-resumes.

[Anden]

Very well, that's exactly (in theory!) how a network transfer should/could work.

Don't forget to take into account that there could be other transmission (from another thread or even from completely different clients) in between the file transfer. Thus your "couple of hours" routine needs at least some kind of packet- and sender-id, too.

Looking forward to your code ...

I've given up on that matter after the principal design because i thought: Hey, why invent the wheel a second time (in at least a couple of hours )? There are already Send/ReceiveNetworkFile routines ready to use ...

BTW:
New network lib seems to be more stable, couldn't reproduce problem 1 again (though i didn't try too hard :.-)).

2 is still possible if you close the connection on the "wrong" side (sender).

3 is still missing (which hurts). But would solve 2 ...

File size limit for 512 RAM is ~32MB (1GB ~ 64 MB). Bigger files fail to send with return code 1.