"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:46f45443$1@newsgroups.borland.com...
>
> "Jamie Dale" <jamie.dale@yahoo.com> wrote in message
> news:46f437f3$1@newsgroups.borland.com...
>
>> I've got the hang of direct file transfers between TIdTCPServer/Client
>> BUT I've recently realised that if the file needs to be transferred
>> THROUGH the serve to another client in real time I'm stuffed!
>
> Send a request to the server specifying the target client. If the server
> finds the client, it keeps track of which connection belongs to that
> client.
> Then, for each data block for the transfer that the server receives from
> the
> sending client, it forwards that block to the tracked connection, making
> sure not to interfer with any other data that may be sent to that client
> at
> the same time.
Sounds simple enough, but when I send the entire file using SendStream() I'm
stuffed! Thats because SendStream doesnt break it down into blocks (or at
least it doesn't allow access to them unless I edit the Indy source).
Therefore, while the Senders AThread is recieving the file, how am I
supposed to initiate another thread to send it? - The Tx'ing thread would
need to read filestream data from the RX'ing thread which is still using the
filestream!
Any hints/tips please Remy?
>
> That is not a particularly efficient approach to the problem, though.
> What
> is wrong with using a second socket?
Well I am. When the main client receives a request for a file transfer, it
opens another form which in turn has it's own client & thread to use it.
> If successful, that listening IP/Port is given to
> the sending client, who then attempts to connect directly to the target
> client. About the only time it wouldn't work is if neither client can
> connect to the other, such as when both parties are behind a firewall
> without adequate rights, or both are behind routers without the transfer
> ports forwarded, or a combination of the two.
Yes, I clearly understood this principle already. Thats why I want to relay
the file through the server so that the clients literally only need to make
an outbound connection using TIdTCPClient. That way I don't need to worry
about firewalls, routers, etc. Of course the main server will have this
issue to overcome which is why I'm bundling it with uPNP support to make
things a bit easier on SOME systems & networks.
>> I had a thought about using the OnWork event to work out how much
>> data had been received and then forward it on to the receiving client
>> but I think that might delay the next read/OnWork from the sender.
>
> That will not help you at all. Those events do not give you the actual
> data.
True, but hear me out as there are ways of calculating the data! The idea
was that the OnWork event could calculate how much data has been received
and then, it could read that data from the FileStream and send it on to the
other client. The procedure could work out the data size from AWorkCount and
the ReceiveBuffer size. Of course that brings up more challenges with the
FileStream already being in use.
Do you have any other suggestions please Remy? - I can only really work with
the prospect of relaying the file through the server. I know it isn't ideal,
but hey thats life (and my strategy for the time being..).
TIA
