Re: client server file transfer

Yes. Well, at least I think. From reading the Perl Cookbook's section on sockets and client/server connections, what I gather is that the way you are implementing it, there is no way for the one to tell the other is done writing; and no way for the other to tell the one is done reading. This causes a server hang. There's probably some info on this if you search this site(or Yahoo, or another search engine).

update: Right problem, wrong solution. I was thinking of fork's; sorry. Though some good suggestions have already been offered, so I'll just leave it at that.

Comment on Re: client server file transfer

Replies are listed 'Best First'.
Re: Re: client server file transfer by Boots111 (Hermit) on Jun 23, 2001 at 01:12 UTC
I don't understand how that would work at all... The SendFile function has not access to OUT. (OUT is on the client program which is on an entirely different computer than then the server) Regardless, I tried that and it does not seem to work, are you sure that the book did not mean to send a "close OUT" variable after the file? Although thanks for the input, the concept of not being sure whether they had finished writing back and forth was what I had suspected. I just want to get a concrete verification Boots	[reply]
Re: Re: Re: client server file transfer by clintp (Curate) on Jun 23, 2001 at 07:02 UTC
A socket is just a stream. How do you know when one rain's water ends and another begins in a river? You're going to have to write some kind of mark on the stream so the receiving end knows when things are done, or send and out-of-band message. One kind of mark is to simply shut down the socket on the sending end (close $to in Sendfile). The client can sense this. If you want to be absolutely sure the whole thing got over there, make the last few (fixed length) bytes a checksum of some kind. If you insist on keeping the socket open, then you're going to have to send a marker just like you are now. Just make sure it's NEVER going to happen in mid-stream though. You could mimic what multipart MIME does and send a long, unique string at the beginning of the stream and another at the end. (Heck, doing that lets you set $/ to the closing string. Some nice code bumming if you're up for it.)	[reply]