Re: [twsocket] Cannot change port if not closed
Thanks for the information Wilfried.
One thing I have realised is that my outputDebug messages are not showing
(they were showing when I was using indy).
You said that I should have a working message pump. Not sure what you mean
here?
Thanks.
Sham.
From: Wilfried Mestdagh [EMAIL PROTECTED]
Reply-To: ICS support mailing twsocket@elists.org
To: ICS support mailing twsocket@elists.org
Subject: Re: [twsocket] Cannot change port if not closed
Date: Sat, 8 Apr 2006 10:38:45 +0200
Hello Shamresh,
In my client I have set multithreaded to true (but not on the server).
No. Multithreaded is if you create the component in a thread other than
the main thread. However I'm not sure this is related to your problem.
I have just moved over from indy, so non blocking events are giving me a
bit
of a headache.
You will get used to it very fast. After all, windows / delphi works
also event driven. Some hints could be (maybe related to your problem):
- dont call the message pump from withing an event. This include also a
modal form (like ShowMessage), or (bad written) components that call
it internally. If you call the message pump then the event can get
re-entered at that moment.
- write a state machine. Some event fire and depending on the state you
can take the right action.
- always have a working message pump. If you block the message pump the
component will stop working until it pumps again.
- dont write wait loops. it is considered as bad programming technique.
You also dont write a wait loop waiting until a button is clicked :)
---
Rgds, Wilfried [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
http://www.mestdagh.biz
Saturday, April 8, 2006, 10:11, Shamresh Khan wrote:
Hi to all,
I have just moved over from indy, so non blocking events are giving me a
bit
of a headache.
I have a number of files that are uploaded to my custom server.
I get an exception raided Cannot change port if not closed after
several
files have been uploaded.
In my client I have set multithreaded to true (but not on the server).
My server is listening on port 21 and I am not clear why a port change
exception is raised. The stack dump on the server is :
TCustomWSocket.RaiseException('Cannot change Port if not closed')
TCustomWSocket.SetRemotePort('1849')
TFtpServer.CommandSTOR($E527EC,???,'testFile23.dat-FS=12','')
TFtpServer.ClientCommand(???,???,???)
TFtpCtrlSocket.TriggerCommand(???,???)
TFtpCtrlSocket.TriggerDataAvailable(???)
TCustomWSocket.ASyncReceive(0,[])
TCustomWSocket.Do_FD_READ(???)
TCustomWSocket.WMASyncSelect((1025, 1456, 1, 66179, 1456, 0, 1, 0, 643,
1))
TCustomWSocket.WndProc((1025, 1456, 1, 66179, 1456, 0, 1, 0, 643, 1))
XSocketWindowProc(???,???,1456,1)
Any help would be appreciated.
Sham.
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] Cannot change port if not closed
I have tested my client with another FTP server and it seems to work.
So the problem could be with my custom FTP server.
In my ftp Server I do custom processing in StoreSessionClosedEvent. The only
other event I have is a Authenticate event.
Do I have to do anything different on the server if I am using ftp clients
in threads?
Sham.
From: Shamresh Khan [EMAIL PROTECTED]
Reply-To: ICS support mailing twsocket@elists.org
To: twsocket@elists.org
Subject: Re: [twsocket] Cannot change port if not closed
Date: Sat, 08 Apr 2006 09:02:02 +
Thanks for the information Wilfried.
One thing I have realised is that my outputDebug messages are not showing
(they were showing when I was using indy).
You said that I should have a working message pump. Not sure what you mean
here?
Thanks.
Sham.
From: Wilfried Mestdagh [EMAIL PROTECTED]
Reply-To: ICS support mailing twsocket@elists.org
To: ICS support mailing twsocket@elists.org
Subject: Re: [twsocket] Cannot change port if not closed
Date: Sat, 8 Apr 2006 10:38:45 +0200
Hello Shamresh,
In my client I have set multithreaded to true (but not on the server).
No. Multithreaded is if you create the component in a thread other than
the main thread. However I'm not sure this is related to your problem.
I have just moved over from indy, so non blocking events are giving me
a
bit
of a headache.
You will get used to it very fast. After all, windows / delphi works
also event driven. Some hints could be (maybe related to your problem):
- dont call the message pump from withing an event. This include also a
modal form (like ShowMessage), or (bad written) components that call
it internally. If you call the message pump then the event can get
re-entered at that moment.
- write a state machine. Some event fire and depending on the state you
can take the right action.
- always have a working message pump. If you block the message pump the
component will stop working until it pumps again.
- dont write wait loops. it is considered as bad programming technique.
You also dont write a wait loop waiting until a button is clicked :)
---
Rgds, Wilfried [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
http://www.mestdagh.biz
Saturday, April 8, 2006, 10:11, Shamresh Khan wrote:
Hi to all,
I have just moved over from indy, so non blocking events are giving me
a
bit
of a headache.
I have a number of files that are uploaded to my custom server.
I get an exception raided Cannot change port if not closed after
several
files have been uploaded.
In my client I have set multithreaded to true (but not on the server).
My server is listening on port 21 and I am not clear why a port change
exception is raised. The stack dump on the server is :
TCustomWSocket.RaiseException('Cannot change Port if not closed')
TCustomWSocket.SetRemotePort('1849')
TFtpServer.CommandSTOR($E527EC,???,'testFile23.dat-FS=12','')
TFtpServer.ClientCommand(???,???,???)
TFtpCtrlSocket.TriggerCommand(???,???)
TFtpCtrlSocket.TriggerDataAvailable(???)
TCustomWSocket.ASyncReceive(0,[])
TCustomWSocket.Do_FD_READ(???)
TCustomWSocket.WMASyncSelect((1025, 1456, 1, 66179, 1456, 0, 1, 0,
643,
1))
TCustomWSocket.WndProc((1025, 1456, 1, 66179, 1456, 0, 1, 0, 643, 1))
XSocketWindowProc(???,???,1456,1)
Any help would be appreciated.
Sham.
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] Cannot change port if not closed
Hello Sham,
One thing I have realised is that my outputDebug messages are not showing
(they were showing when I was using indy).
The main difference is that your code is now operating in the thread
context where you have created the component. How do you show the debug
messages ?
You said that I should have a working message pump. Not sure what you mean
Each (hidden) window in windows has to have a working message pump.
Delphi is hiding that for you. For example you create a form, and Delphi
take care of it. It will pump until you for example click a button. Then
your code will execute and as long as your code block run you block the
pump. When you exit the buttonClick then Delphi enters the message pump
again.
From your code you can pump also by calling Application.Processmessages.
In most (if not all) case this is never needed. It can also be very bad
because you enter the pump yourself, so a pending message (eg an event
or a mouse click or whatever) will execute. Doing this it is possible
you re-enter your own code block while it is executing.
So normally you dont have to worry about because you normally have a
working message pump, also if you create a window yourself with
AllocHWND witch have a WndProc argument witch is called by the message
pump that Delphi create for you.
It is different if you do something in a thread. If you create a
component in a thread then TWSocket will create his hidden window.
Fortunally TWSocket has his own (thread safe) message pump on board, so
you have to set multithread True and call it yourself. You can also easy
create a message pump with GetMessage api function.
I hope this infomration make sence.
---
Rgds, Wilfried [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
http://www.mestdagh.biz
Saturday, April 8, 2006, 11:02, Shamresh Khan wrote:
Thanks for the information Wilfried.
One thing I have realised is that my outputDebug messages are not showing
(they were showing when I was using indy).
You said that I should have a working message pump. Not sure what you mean
here?
Thanks.
Sham.
From: Wilfried Mestdagh [EMAIL PROTECTED]
Reply-To: ICS support mailing twsocket@elists.org
To: ICS support mailing twsocket@elists.org
Subject: Re: [twsocket] Cannot change port if not closed
Date: Sat, 8 Apr 2006 10:38:45 +0200
Hello Shamresh,
In my client I have set multithreaded to true (but not on the server).
No. Multithreaded is if you create the component in a thread other than
the main thread. However I'm not sure this is related to your problem.
I have just moved over from indy, so non blocking events are giving me a
bit
of a headache.
You will get used to it very fast. After all, windows / delphi works
also event driven. Some hints could be (maybe related to your problem):
- dont call the message pump from withing an event. This include also a
modal form (like ShowMessage), or (bad written) components that call
it internally. If you call the message pump then the event can get
re-entered at that moment.
- write a state machine. Some event fire and depending on the state you
can take the right action.
- always have a working message pump. If you block the message pump the
component will stop working until it pumps again.
- dont write wait loops. it is considered as bad programming technique.
You also dont write a wait loop waiting until a button is clicked :)
---
Rgds, Wilfried [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
http://www.mestdagh.biz
Saturday, April 8, 2006, 10:11, Shamresh Khan wrote:
Hi to all,
I have just moved over from indy, so non blocking events are giving me a
bit
of a headache.
I have a number of files that are uploaded to my custom server.
I get an exception raided Cannot change port if not closed after
several
files have been uploaded.
In my client I have set multithreaded to true (but not on the server).
My server is listening on port 21 and I am not clear why a port change
exception is raised. The stack dump on the server is :
TCustomWSocket.RaiseException('Cannot change Port if not closed')
TCustomWSocket.SetRemotePort('1849')
TFtpServer.CommandSTOR($E527EC,???,'testFile23.dat-FS=12','')
TFtpServer.ClientCommand(???,???,???)
TFtpCtrlSocket.TriggerCommand(???,???)
TFtpCtrlSocket.TriggerDataAvailable(???)
TCustomWSocket.ASyncReceive(0,[])
TCustomWSocket.Do_FD_READ(???)
TCustomWSocket.WMASyncSelect((1025, 1456, 1, 66179, 1456, 0, 1, 0, 643,
1))
TCustomWSocket.WndProc((1025, 1456, 1, 66179, 1456, 0, 1, 0, 643, 1))
XSocketWindowProc(???,???,1456,1)
Any help would be appreciated.
Sham.
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at
Re: [twsocket] Cannot change port if not closed
Hello Shamresh,
Do I have to do anything different on the server if I am using ftp clients
in threads?
Yes. By default TFTPServer will create his clients in the thread context
where you have created the component, eg the main thread. Normally you
dont need threads, because the component can handle thousands of clients
the same time using coorporative multitasking.
But if you have to do a very lengthy operation you block the message
pump during this operation. So at that moment all communication will
stop. If it is not too long no problem, winsock will stay on executing
until his buffers ar full, and when your lengty code finish the
component will start firing events again.
But if you really need a thread you can do several things. You can
attach the client to a thread do the lengty thing and detach it again,
because it has to be attached to the thread where it is created for
destruction (that's the way windows work).
Another way is to start a thread for the length operation and give the
thread the socket handle. Later when the thread finish it can do (eg
send something) with that socket again and meanwile all other code stay
executing.
But are you sure you want to operate each connection in a separate
thread ? Normally it is really not needed !
---
Rgds, Wilfried [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
http://www.mestdagh.biz
Saturday, April 8, 2006, 11:27, Shamresh Khan wrote:
I have tested my client with another FTP server and it seems to work.
So the problem could be with my custom FTP server.
In my ftp Server I do custom processing in StoreSessionClosedEvent. The only
other event I have is a Authenticate event.
Do I have to do anything different on the server if I am using ftp clients
in threads?
Sham.
From: Shamresh Khan [EMAIL PROTECTED]
Reply-To: ICS support mailing twsocket@elists.org
To: twsocket@elists.org
Subject: Re: [twsocket] Cannot change port if not closed
Date: Sat, 08 Apr 2006 09:02:02 +
Thanks for the information Wilfried.
One thing I have realised is that my outputDebug messages are not showing
(they were showing when I was using indy).
You said that I should have a working message pump. Not sure what you mean
here?
Thanks.
Sham.
From: Wilfried Mestdagh [EMAIL PROTECTED]
Reply-To: ICS support mailing twsocket@elists.org
To: ICS support mailing twsocket@elists.org
Subject: Re: [twsocket] Cannot change port if not closed
Date: Sat, 8 Apr 2006 10:38:45 +0200
Hello Shamresh,
In my client I have set multithreaded to true (but not on the server).
No. Multithreaded is if you create the component in a thread other than
the main thread. However I'm not sure this is related to your problem.
I have just moved over from indy, so non blocking events are giving me
a
bit
of a headache.
You will get used to it very fast. After all, windows / delphi works
also event driven. Some hints could be (maybe related to your problem):
- dont call the message pump from withing an event. This include also a
modal form (like ShowMessage), or (bad written) components that call
it internally. If you call the message pump then the event can get
re-entered at that moment.
- write a state machine. Some event fire and depending on the state you
can take the right action.
- always have a working message pump. If you block the message pump the
component will stop working until it pumps again.
- dont write wait loops. it is considered as bad programming technique.
You also dont write a wait loop waiting until a button is clicked :)
---
Rgds, Wilfried [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
http://www.mestdagh.biz
Saturday, April 8, 2006, 10:11, Shamresh Khan wrote:
Hi to all,
I have just moved over from indy, so non blocking events are giving me
a
bit
of a headache.
I have a number of files that are uploaded to my custom server.
I get an exception raided Cannot change port if not closed after
several
files have been uploaded.
In my client I have set multithreaded to true (but not on the server).
My server is listening on port 21 and I am not clear why a port change
exception is raised. The stack dump on the server is :
TCustomWSocket.RaiseException('Cannot change Port if not closed')
TCustomWSocket.SetRemotePort('1849')
TFtpServer.CommandSTOR($E527EC,???,'testFile23.dat-FS=12','')
TFtpServer.ClientCommand(???,???,???)
TFtpCtrlSocket.TriggerCommand(???,???)
TFtpCtrlSocket.TriggerDataAvailable(???)
TCustomWSocket.ASyncReceive(0,[])
TCustomWSocket.Do_FD_READ(???)
TCustomWSocket.WMASyncSelect((1025, 1456, 1, 66179, 1456, 0, 1, 0,
643,
1))
TCustomWSocket.WndProc((1025, 1456, 1, 66179, 1456, 0, 1, 0, 643, 1))
XSocketWindowProc(???,???,1456,1)
Any help would be appreciated.
Sham.
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Re: [twsocket] Cannot change port if not closed
How are the clients related to the server? If there is no connection (the server does not wait for data from the clients) then it is as you understood, they can co-exist. If otherwise, then it is diffucult with ICS--we did it here for HTTPS Reverse Proxy, I know what I am saying... Regards, SZ - Original Message - From: Shamresh Khan [EMAIL PROTECTED] To: twsocket@elists.org Sent: Saturday, April 08, 2006 1:24 PM Subject: Re: [twsocket] Cannot change port if not closed Hi Wilfried, This is what we had with indy. We created a number of threads and in each thread we had a indy ftp client. Each client puts (ftps) as file and then updates its corresponding progress bar. Once the thread has finished sending all the data that was allocated to it (i.e. a number of files), it waits until there are more files allocated. Since indy is blocking, this worked nicely, each thread waiting for data. Now, I am trying to change this model to work with asynchronous ICS components. Are you saying that I should not use the threads and simply create the ftp clients in normal objects? The onrequestDone will be fired within the ftp connection thread. Would this allow me to have multiple ftp clients each sending data and have the progress bars updated simultaneously? Sham. From: Wilfried Mestdagh [EMAIL PROTECTED] Reply-To: ICS support mailing twsocket@elists.org To: ICS support mailing twsocket@elists.org Subject: Re: [twsocket] Cannot change port if not closed Date: Sat, 8 Apr 2006 11:43:18 +0200 Hello Shamresh, Do I have to do anything different on the server if I am using ftp clients in threads? Yes. By default TFTPServer will create his clients in the thread context where you have created the component, eg the main thread. Normally you dont need threads, because the component can handle thousands of clients the same time using coorporative multitasking. But if you have to do a very lengthy operation you block the message pump during this operation. So at that moment all communication will stop. If it is not too long no problem, winsock will stay on executing until his buffers ar full, and when your lengty code finish the component will start firing events again. But if you really need a thread you can do several things. You can attach the client to a thread do the lengty thing and detach it again, because it has to be attached to the thread where it is created for destruction (that's the way windows work). Another way is to start a thread for the length operation and give the thread the socket handle. Later when the thread finish it can do (eg send something) with that socket again and meanwile all other code stay executing. But are you sure you want to operate each connection in a separate thread ? Normally it is really not needed ! --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Saturday, April 8, 2006, 11:27, Shamresh Khan wrote: I have tested my client with another FTP server and it seems to work. So the problem could be with my custom FTP server. In my ftp Server I do custom processing in StoreSessionClosedEvent. The only other event I have is a Authenticate event. Do I have to do anything different on the server if I am using ftp clients in threads? Sham. From: Shamresh Khan [EMAIL PROTECTED] Reply-To: ICS support mailing twsocket@elists.org To: twsocket@elists.org Subject: Re: [twsocket] Cannot change port if not closed Date: Sat, 08 Apr 2006 09:02:02 + Thanks for the information Wilfried. One thing I have realised is that my outputDebug messages are not showing (they were showing when I was using indy). You said that I should have a working message pump. Not sure what you mean here? Thanks. Sham. From: Wilfried Mestdagh [EMAIL PROTECTED] Reply-To: ICS support mailing twsocket@elists.org To: ICS support mailing twsocket@elists.org Subject: Re: [twsocket] Cannot change port if not closed Date: Sat, 8 Apr 2006 10:38:45 +0200 Hello Shamresh, In my client I have set multithreaded to true (but not on the server). No. Multithreaded is if you create the component in a thread other than the main thread. However I'm not sure this is related to your problem. I have just moved over from indy, so non blocking events are giving me a bit of a headache. You will get used to it very fast. After all, windows / delphi works also event driven. Some hints could be (maybe related to your problem): - dont call the message pump from withing an event. This include also a modal form (like ShowMessage), or (bad written) components that call it internally. If you call the message pump then the event can get re-entered at that moment. - write a state machine. Some event fire and depending on the state you can take the right action. - always have a working message pump. If you block the message pump
Re: [twsocket] Cannot change port if not closed
Hi, How are the clients related to the server? Not sure what you mean here. I have a client object which has a thread associated with it. Data that needs to be ftp'd is passed as a series of objects to the client object. The client object would then do a ftp connect and then begin ftping the files. Once finished, the connection is disconnected and then ftp thread waits until more objects are passed to it. This is the way it worked for indy. If I get rid of the threads (since non blocking ICS), would the above model still work (using onrequestDone as a state machine)? Or can I use ICS in a blocking fashion and hence I use the same model above? Sham. From: Fastream Technologies [EMAIL PROTECTED] Reply-To: ICS support mailing twsocket@elists.org To: ICS support mailing twsocket@elists.org Subject: Re: [twsocket] Cannot change port if not closed Date: Sat, 8 Apr 2006 13:27:39 +0300 How are the clients related to the server? If there is no connection (the server does not wait for data from the clients) then it is as you understood, they can co-exist. If otherwise, then it is diffucult with ICS--we did it here for HTTPS Reverse Proxy, I know what I am saying... Regards, SZ - Original Message - From: Shamresh Khan [EMAIL PROTECTED] To: twsocket@elists.org Sent: Saturday, April 08, 2006 1:24 PM Subject: Re: [twsocket] Cannot change port if not closed Hi Wilfried, This is what we had with indy. We created a number of threads and in each thread we had a indy ftp client. Each client puts (ftps) as file and then updates its corresponding progress bar. Once the thread has finished sending all the data that was allocated to it (i.e. a number of files), it waits until there are more files allocated. Since indy is blocking, this worked nicely, each thread waiting for data. Now, I am trying to change this model to work with asynchronous ICS components. Are you saying that I should not use the threads and simply create the ftp clients in normal objects? The onrequestDone will be fired within the ftp connection thread. Would this allow me to have multiple ftp clients each sending data and have the progress bars updated simultaneously? Sham. From: Wilfried Mestdagh [EMAIL PROTECTED] Reply-To: ICS support mailing twsocket@elists.org To: ICS support mailing twsocket@elists.org Subject: Re: [twsocket] Cannot change port if not closed Date: Sat, 8 Apr 2006 11:43:18 +0200 Hello Shamresh, Do I have to do anything different on the server if I am using ftp clients in threads? Yes. By default TFTPServer will create his clients in the thread context where you have created the component, eg the main thread. Normally you dont need threads, because the component can handle thousands of clients the same time using coorporative multitasking. But if you have to do a very lengthy operation you block the message pump during this operation. So at that moment all communication will stop. If it is not too long no problem, winsock will stay on executing until his buffers ar full, and when your lengty code finish the component will start firing events again. But if you really need a thread you can do several things. You can attach the client to a thread do the lengty thing and detach it again, because it has to be attached to the thread where it is created for destruction (that's the way windows work). Another way is to start a thread for the length operation and give the thread the socket handle. Later when the thread finish it can do (eg send something) with that socket again and meanwile all other code stay executing. But are you sure you want to operate each connection in a separate thread ? Normally it is really not needed ! --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Saturday, April 8, 2006, 11:27, Shamresh Khan wrote: I have tested my client with another FTP server and it seems to work. So the problem could be with my custom FTP server. In my ftp Server I do custom processing in StoreSessionClosedEvent. The only other event I have is a Authenticate event. Do I have to do anything different on the server if I am using ftp clients in threads? Sham. From: Shamresh Khan [EMAIL PROTECTED] Reply-To: ICS support mailing twsocket@elists.org To: twsocket@elists.org Subject: Re: [twsocket] Cannot change port if not closed Date: Sat, 08 Apr 2006 09:02:02 + Thanks for the information Wilfried. One thing I have realised is that my outputDebug messages are not showing (they were showing when I was using indy). You said that I should have a working message pump. Not sure what you mean here? Thanks. Sham. From: Wilfried Mestdagh [EMAIL PROTECTED] Reply-To: ICS support mailing twsocket@elists.org To: ICS support mailing twsocket@elists.org Subject: Re: [twsocket] Cannot
Re: [twsocket] Cannot change port if not closed
Hello Sham, Yes. You can leave the programming model the same since it is mostly a good technique to make an object for the communication, containing the ftp client. And yes you can make it normal non threaded objects. As before you create as many as you want to let file transfer simulanously, and they should do their job all in parallel. Each method call that has to do with FTP will generate an OnRequestDone where you can take next action depending on the state of the ftp client. So there you have to check the state, and of course also the Winsock and FTP error if there is one. Be carefull with updating status bar. Component will run in same thread as your display, and GUI updating is very slow. So do the updating of the statusbar not in real time, but every few seconds or so. If you should do it each time some packet is transmitted then you will slow down everything (depending on the connection speed). --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Saturday, April 8, 2006, 12:24, Shamresh Khan wrote: Hi Wilfried, This is what we had with indy. We created a number of threads and in each thread we had a indy ftp client. Each client puts (ftps) as file and then updates its corresponding progress bar. Once the thread has finished sending all the data that was allocated to it (i.e. a number of files), it waits until there are more files allocated. Since indy is blocking, this worked nicely, each thread waiting for data. Now, I am trying to change this model to work with asynchronous ICS components. Are you saying that I should not use the threads and simply create the ftp clients in normal objects? The onrequestDone will be fired within the ftp connection thread. Would this allow me to have multiple ftp clients each sending data and have the progress bars updated simultaneously? Sham. From: Wilfried Mestdagh [EMAIL PROTECTED] Reply-To: ICS support mailing twsocket@elists.org To: ICS support mailing twsocket@elists.org Subject: Re: [twsocket] Cannot change port if not closed Date: Sat, 8 Apr 2006 11:43:18 +0200 Hello Shamresh, Do I have to do anything different on the server if I am using ftp clients in threads? Yes. By default TFTPServer will create his clients in the thread context where you have created the component, eg the main thread. Normally you dont need threads, because the component can handle thousands of clients the same time using coorporative multitasking. But if you have to do a very lengthy operation you block the message pump during this operation. So at that moment all communication will stop. If it is not too long no problem, winsock will stay on executing until his buffers ar full, and when your lengty code finish the component will start firing events again. But if you really need a thread you can do several things. You can attach the client to a thread do the lengty thing and detach it again, because it has to be attached to the thread where it is created for destruction (that's the way windows work). Another way is to start a thread for the length operation and give the thread the socket handle. Later when the thread finish it can do (eg send something) with that socket again and meanwile all other code stay executing. But are you sure you want to operate each connection in a separate thread ? Normally it is really not needed ! --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Saturday, April 8, 2006, 11:27, Shamresh Khan wrote: I have tested my client with another FTP server and it seems to work. So the problem could be with my custom FTP server. In my ftp Server I do custom processing in StoreSessionClosedEvent. The only other event I have is a Authenticate event. Do I have to do anything different on the server if I am using ftp clients in threads? Sham. From: Shamresh Khan [EMAIL PROTECTED] Reply-To: ICS support mailing twsocket@elists.org To: twsocket@elists.org Subject: Re: [twsocket] Cannot change port if not closed Date: Sat, 08 Apr 2006 09:02:02 + Thanks for the information Wilfried. One thing I have realised is that my outputDebug messages are not showing (they were showing when I was using indy). You said that I should have a working message pump. Not sure what you mean here? Thanks. Sham. From: Wilfried Mestdagh [EMAIL PROTECTED] Reply-To: ICS support mailing twsocket@elists.org To: ICS support mailing twsocket@elists.org Subject: Re: [twsocket] Cannot change port if not closed Date: Sat, 8 Apr 2006 10:38:45 +0200 Hello Shamresh, In my client I have set multithreaded to true (but not on the server). No. Multithreaded is if you create the component in a thread other than the main thread. However I'm not sure this is related to your problem. I have just moved over from indy, so non blocking events are giving me a bit of a headache.
Re: [twsocket] Cannot change port if not closed
Hello Shamresh, Or can I use ICS in a blocking fashion and hence I use the same model above? Yes you can. FTP client has also sync methods. However the use of it is not encouraged. Generally it is better to do it all async as the components are designed as sutch. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Saturday, April 8, 2006, 13:02, Shamresh Khan wrote: Hi, How are the clients related to the server? Not sure what you mean here. I have a client object which has a thread associated with it. Data that needs to be ftp'd is passed as a series of objects to the client object. The client object would then do a ftp connect and then begin ftping the files. Once finished, the connection is disconnected and then ftp thread waits until more objects are passed to it. This is the way it worked for indy. If I get rid of the threads (since non blocking ICS), would the above model still work (using onrequestDone as a state machine)? Or can I use ICS in a blocking fashion and hence I use the same model above? Sham. From: Fastream Technologies [EMAIL PROTECTED] Reply-To: ICS support mailing twsocket@elists.org To: ICS support mailing twsocket@elists.org Subject: Re: [twsocket] Cannot change port if not closed Date: Sat, 8 Apr 2006 13:27:39 +0300 How are the clients related to the server? If there is no connection (the server does not wait for data from the clients) then it is as you understood, they can co-exist. If otherwise, then it is diffucult with ICS--we did it here for HTTPS Reverse Proxy, I know what I am saying... Regards, SZ - Original Message - From: Shamresh Khan [EMAIL PROTECTED] To: twsocket@elists.org Sent: Saturday, April 08, 2006 1:24 PM Subject: Re: [twsocket] Cannot change port if not closed Hi Wilfried, This is what we had with indy. We created a number of threads and in each thread we had a indy ftp client. Each client puts (ftps) as file and then updates its corresponding progress bar. Once the thread has finished sending all the data that was allocated to it (i.e. a number of files), it waits until there are more files allocated. Since indy is blocking, this worked nicely, each thread waiting for data. Now, I am trying to change this model to work with asynchronous ICS components. Are you saying that I should not use the threads and simply create the ftp clients in normal objects? The onrequestDone will be fired within the ftp connection thread. Would this allow me to have multiple ftp clients each sending data and have the progress bars updated simultaneously? Sham. From: Wilfried Mestdagh [EMAIL PROTECTED] Reply-To: ICS support mailing twsocket@elists.org To: ICS support mailing twsocket@elists.org Subject: Re: [twsocket] Cannot change port if not closed Date: Sat, 8 Apr 2006 11:43:18 +0200 Hello Shamresh, Do I have to do anything different on the server if I am using ftp clients in threads? Yes. By default TFTPServer will create his clients in the thread context where you have created the component, eg the main thread. Normally you dont need threads, because the component can handle thousands of clients the same time using coorporative multitasking. But if you have to do a very lengthy operation you block the message pump during this operation. So at that moment all communication will stop. If it is not too long no problem, winsock will stay on executing until his buffers ar full, and when your lengty code finish the component will start firing events again. But if you really need a thread you can do several things. You can attach the client to a thread do the lengty thing and detach it again, because it has to be attached to the thread where it is created for destruction (that's the way windows work). Another way is to start a thread for the length operation and give the thread the socket handle. Later when the thread finish it can do (eg send something) with that socket again and meanwile all other code stay executing. But are you sure you want to operate each connection in a separate thread ? Normally it is really not needed ! --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Saturday, April 8, 2006, 11:27, Shamresh Khan wrote: I have tested my client with another FTP server and it seems to work. So the problem could be with my custom FTP server. In my ftp Server I do custom processing in StoreSessionClosedEvent. The only other event I have is a Authenticate event. Do I have to do anything different on the server if I am using ftp clients in threads? Sham. From: Shamresh Khan [EMAIL PROTECTED] Reply-To: ICS support mailing twsocket@elists.org To: twsocket@elists.org Subject: Re: [twsocket] Cannot change port if not closed Date: Sat, 08 Apr 2006 09:02:02 + Thanks for the information
[twsocket] Need a fast cache class?
Hi, With help of Benjamin Stadin I've written a fast cache-like data storage based on two linked AVL-Trees for primary and secondary indexing. http://www.duodata.de/misc/delphi/AvlCache.zip Included is a small demo that demonstrates use and speed of the TCacheTree class. Beside SSL session caching TCacheTree could be also very usefull for other purposes. Performance messured on a Pentium D 2.80GHZ: Preparing random word list.. // englisch words up to ~18 chars long Word list has 30322 entries Inserting 30322 entries.. Duration = 86 ms Now starting 10.000 random searches.. Duration = 19 ms --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Cannot change port if not closed
Hello Wilfried, I have done as you have said and it seems to work. I have removed the threads and let the onRequestDone Event handle the processing of files in each FTP Worker object. But as you also mentioned, the GUI is really sluggish and the app freezes when I try to move it. That is why with Indy we had the threads so that we could continue using the app whilst the ftp worker objects were working away in the background. What I did with Indy was do a postMessage back to the main form which contained the current file size transferred (i.e. the OnWorkProgress counter). This way if a large file was being transferred we could see how much of it had be done. Is there anyway to make the apps more responsive (i.e. get the gui to update with the counter information)? Also would it still work if we have several FTP servers in use at one time? Thanks for all the help Sham. From: Wilfried Mestdagh [EMAIL PROTECTED] Reply-To: ICS support mailing twsocket@elists.org To: ICS support mailing twsocket@elists.org Subject: Re: [twsocket] Cannot change port if not closed Date: Sat, 8 Apr 2006 13:44:05 +0200 Hello Sham, Yes. You can leave the programming model the same since it is mostly a good technique to make an object for the communication, containing the ftp client. And yes you can make it normal non threaded objects. As before you create as many as you want to let file transfer simulanously, and they should do their job all in parallel. Each method call that has to do with FTP will generate an OnRequestDone where you can take next action depending on the state of the ftp client. So there you have to check the state, and of course also the Winsock and FTP error if there is one. Be carefull with updating status bar. Component will run in same thread as your display, and GUI updating is very slow. So do the updating of the statusbar not in real time, but every few seconds or so. If you should do it each time some packet is transmitted then you will slow down everything (depending on the connection speed). --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Saturday, April 8, 2006, 12:24, Shamresh Khan wrote: Hi Wilfried, This is what we had with indy. We created a number of threads and in each thread we had a indy ftp client. Each client puts (ftps) as file and then updates its corresponding progress bar. Once the thread has finished sending all the data that was allocated to it (i.e. a number of files), it waits until there are more files allocated. Since indy is blocking, this worked nicely, each thread waiting for data. Now, I am trying to change this model to work with asynchronous ICS components. Are you saying that I should not use the threads and simply create the ftp clients in normal objects? The onrequestDone will be fired within the ftp connection thread. Would this allow me to have multiple ftp clients each sending data and have the progress bars updated simultaneously? Sham. From: Wilfried Mestdagh [EMAIL PROTECTED] Reply-To: ICS support mailing twsocket@elists.org To: ICS support mailing twsocket@elists.org Subject: Re: [twsocket] Cannot change port if not closed Date: Sat, 8 Apr 2006 11:43:18 +0200 Hello Shamresh, Do I have to do anything different on the server if I am using ftp clients in threads? Yes. By default TFTPServer will create his clients in the thread context where you have created the component, eg the main thread. Normally you dont need threads, because the component can handle thousands of clients the same time using coorporative multitasking. But if you have to do a very lengthy operation you block the message pump during this operation. So at that moment all communication will stop. If it is not too long no problem, winsock will stay on executing until his buffers ar full, and when your lengty code finish the component will start firing events again. But if you really need a thread you can do several things. You can attach the client to a thread do the lengty thing and detach it again, because it has to be attached to the thread where it is created for destruction (that's the way windows work). Another way is to start a thread for the length operation and give the thread the socket handle. Later when the thread finish it can do (eg send something) with that socket again and meanwile all other code stay executing. But are you sure you want to operate each connection in a separate thread ? Normally it is really not needed ! --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Saturday, April 8, 2006, 11:27, Shamresh Khan wrote: I have tested my client with another FTP server and it seems to work. So the problem could be with my custom FTP server. In my ftp Server I do custom processing in StoreSessionClosedEvent. The only other event I have is a
Re: [twsocket] Cannot change port if not closed
Shamresh Khan wrote: Hello Wilfried, I have done as you have said and it seems to work. I have removed the threads and let the onRequestDone Event handle the processing of files in each FTP Worker object. But as you also mentioned, the GUI is really sluggish and the app freezes when I try to move it. It depends on transfer speed. If you have a very fast line it's probably better to have a single worker thread for all FtpCli instances. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
