Newsgroups : Borland : borland.public.delphi.internet.winsock : 2007 Sep : Re: File Transfers - Indy9

www.cryer.info
Managed Newsgroup Archive

Re: File Transfers - Indy9

Subject:Re: File Transfers - Indy9
Posted by:"Remy Lebeau (TeamB)" (no.spam@no.spam.com)
Date:Fri, 21 Sep 2007 16:30:33

"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.

That is not a particularly efficient approach to the problem, though.  What
is wrong with using a second socket?  That is what most IM programs do
nowadays.  If the server finds the target client, it requests that client to
open a listening socket.  If successful, that listening IP/Port is given to
the sending client, who then attempts to connect directly to the target
client.  If that connection is not successful, then the roles are reversed -
the sending client opens a listening socket that the target client tries to
connect to.  If either is successful, then the file can be transfered from
one client to the other without going through the server at all.  This
approach works just fine in most situations (including through firewalls and
routers).  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.  Otherwise, as long as one
party is open for access (firewall rights are ok, and/or the port is
forwarded), the other can reach the other party.

> 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.


Gambit

Replies:

In response to:

www.cryer.info
Managed Newsgroup Archive