🚀 go-pugleaf

"Bill Cain" <bill.ctr.cain@faa.gov> wrote in message 
news:4378d734$1@newsgroups.borland.com...

> The problem that I am encountering is that the socket
> does not appear to be accepting data received from a
> client after connecting to the client.  Accept and
> Connection Events are triggered but no Read Event is
> triggered.

You did not specify whether you are using the OnGetThread event to create 
your own reading thread or not.  That is important.  If you are using your 
own thread class, then you should not be using the OnClientRead event at 
all.  On the other hand, if you are using the stock thread class that is 
built into TServerSocket, then the only possible way for the OnClientRead 
event to not be triggered is if either: 1) the client disconnects without 
sending any data; 2) the client stays connected but does not send any data; 
or 3) the main thread is blocked such that TThread::Synchronize() cannot 
trigger the events.


Gambit 

Bill Cain wrote:
> I am writing an FTP client application that uses TServerSocket(as the 
> data connection) in a thread other than the main VCL thread. 

Do you use TClientSocket for the client part ?

 > The
> ServerType is set to stBlockingThread.

stThreadBlocking ?

> The problem that I am encountering is that the socket does not appear to 
> be accepting data received from a client after connecting to the client. 

Sorry. Servers do not connect to clients. A server can only listen and wait
for connections.

>  Accept and Connection Events are triggered but no Read Event is triggered.

The OnRead event will never be triggered with stThreadBlocking. You have
to actively read from a stream.

> Can you tell me why the TServerSocket is not receiving data?

You did not show code where you tried to read from a stream.

>     DataSocket2->Port = ConvertPortString(PortString);

Pleae supply types. Is DataSocket2 a TServerSocket ? If yes why do
you need 2 ?

>     Command = AnsiString("PORT ") + AnsiString(Addr[0]) +\
>     AnsiString(",") + AnsiString(Addr[1]) +\
>     AnsiString(",") + AnsiString(Addr[2]) +\
>         AnsiString(",") + AnsiString(Addr[3]) + PortString;

We cannot check here the contents of Addr.

>     if(Error = DoTransaction(Command))
>     {
>       return Error;
>     }

We cannot check how you implemented DoTransaction.

>           Writeln(AnsiString("NLST"));//List item names

Ditto.

>           while(Wait) //Wait for LIST responses
>           {
>           }

What is Wait ?

Hans.

"Hans Galema" <notused@notused.nl> wrote in message 
news:43790e73$1@newsgroups.borland.com...

> Do you use TClientSocket for the client part ?

That should not matter.  TServerSocket can accept, and communicate with, any 
client socket regardless of the environment it is coming from.  Everything 
ultmately operates on the same socket API anyway.  TCP, and thus socket 
behavior, is standardized across multiple platforms.

> Sorry. Servers do not connect to clients. A server can only
> listen and wait for connections.

In Bill's particular case, he is making his FTP client application open a 
separate listening server socket that the FTP server application will 
connect its own client socket to.  That is one scenerio in how the FTP 
protocol handles data connections.

> The OnRead event will never be triggered with stThreadBlocking.

That is correct only if Bill is not using the TServerSocket's OnGetThread 
event to provide his own cutom thread object for TServerSocket to use for 
each connection.  The default thread object that TServerSocket created by 
default does trigger the OnRead (and OnWrite) event.

> You have to actively read from a stream.

That is not always the case.

> Is DataSocket2 a TServerSocket ?

Given the example FTP commands that Bill showed, then his DataSocket would 
have to be a server socket, since that is what the PORT command requires.

> If yes why do you need 2 ?

He is only using 1 server socket.  He has to be sending his FTP commands 
over a client socket.

> We cannot check here the contents of Addr.

Presumably, Addr has been assigned to the IP that his TServerSocket is 
listening on.


Gambit 

Thanks Remy for your response to Hans.  Your conclusions and assumptions 
about what I am doing is correct.  But I have some additional questions. 
  Please see them below.


Remy Lebeau (TeamB) wrote:
> "Hans Galema" <notused@notused.nl> wrote in message 
> news:43790e73$1@newsgroups.borland.com...
> 
> 
>>Do you use TClientSocket for the client part ?
> 
> 
> That should not matter.  TServerSocket can accept, and communicate with, any 
> client socket regardless of the environment it is coming from.  Everything 
> ultmately operates on the same socket API anyway.  TCP, and thus socket 
> behavior, is standardized across multiple platforms.
> 
> 
>>Sorry. Servers do not connect to clients. A server can only
>>listen and wait for connections.
> 
> 
> In Bill's particular case, he is making his FTP client application open a 
> separate listening server socket that the FTP server application will 
> connect its own client socket to.  That is one scenerio in how the FTP 
> protocol handles data connections.
> 
> 
>>The OnRead event will never be triggered with stThreadBlocking.
> 
> 
> That is correct only if Bill is not using the TServerSocket's OnGetThread 
> event to provide his own cutom thread object for TServerSocket to use for 
> each connection.  The default thread object that TServerSocket created by 
> default does trigger the OnRead (and OnWrite) event.


I am not using the TServerSocket's OnGetThread event to provide my own 
custom thread object.  The statement above seems to be a contradiction. 
  OnClientRead won't trigger if I don't use OnGetThread(that is if I use 
the default thread provided by TServerSocket), but then you say that the 
   default thread does trigger OnRead.  In my case the OnClientRead is 
not being triggered.  Should it be?

Also I have discovered that I can read data from the socket in the 
OnClientConnect event and I can use the ReceiveLength() method the see 
how much data is available if any (although I have read that the value 
may not be accurate).  How can I determine if the data transfer is complete?

I want to check my understanding here.  It is my understanding that 
since my FTP client is executing in a thread other than the main VCL 
thread, that I must use stThreadBlocking mode since the thread does not 
have a message loop/service to trigger serial async events.  Is that 
correct?
> 
> 
>>You have to actively read from a stream.
> 
> 
> That is not always the case.
> 
> 
>>Is DataSocket2 a TServerSocket ?
> 
> 
> Given the example FTP commands that Bill showed, then his DataSocket would 
> have to be a server socket, since that is what the PORT command requires.
> 
> 
>>If yes why do you need 2 ?
> 
> 
> He is only using 1 server socket.  He has to be sending his FTP commands 
> over a client socket.
> 
> 
>>We cannot check here the contents of Addr.
> 
> 
> Presumably, Addr has been assigned to the IP that his TServerSocket is 
> listening on.
> 
> 
> Gambit 
> 
> 

"Bill Cain" <bill.ctr.cain@faa.gov> wrote in message
news:437a3b0b$1@newsgroups.borland.com...

> I am not using the TServerSocket's OnGetThread event
> to provide my own custom thread object.

When using a TServerSocket in blocking mode, it is not strictly a
requirement to do so, but it does make the coding of the connection much
easier if you do provide your own thread.

>   OnClientRead won't trigger if I don't use OnGetThread

Yes, it will.

> In my case the OnClientRead is not being triggered.  Should it be?

Yes, it should be.  Do note, however, that the default thread does use
TThread::Synchronize() to trigger the OnClientRead/Write events.  So if your
main thread is blocked, the events will also be blocked.

> How can I determine if the data transfer is complete?

The data connection will be closed.  That is how the streaming mode of the
FTP protocol is designed to work.

> It is my understanding that since my FTP client is executing
> in a thread other than the main VCL thread, that I must use
> stThreadBlocking mode since the thread does not have a
> message loop/service to trigger serial async events.  Is that
> correct?

A message queue is required for non-blocking sockets, yes.  If no message
queue is available then blocking mode must be used.  Otherwise, add your own
message queue in the thread so that non-blocking sockets can be used.


Gambit

"Bill Cain" <bill.ctr.cain@faa.gov> wrote in message
news:437a3b0b$1@newsgroups.borland.com...

> Thanks Remy for your response to Hans.  Your conclusions
> and assumptions about what I am doing is correct.

In that case, since you are using threads anyway, I would suggest you use a
pre-made FTP component instead of trying to write your own FTP code.  Indy
(http://www.indyproject.org) uses blocking sockets and its TIdFTP component
has extensive support for the FTP protocol, including many of its
extensions.


Gambit