Re: [twsocket] Suggestion: set FLastError on session connect/disconnect
I now trying to implement sync socket actions (I'll need to make DLL so async model doesn't fit). procedure TSockClient.Request; begin if State <> wsConnected then begin Connect; while not (State in [wsConnected, wsClosed]) do MessagePump; if State <> wsConnected then begin //.. Exit; end; end; ...send request... end; Why would you like to implement such code ? You'll just waste CPU cycles. There are a lot of easy way to use async operations in a DLL. If you need to export synchronous functions out of your DLL, I would suggest using a thread withing the DLL, having his own message ump and working purely asynchronoulsy as ICS does so well. Then the exported function will talk to this thread using traditional multithread synchonization mechanisms to looks blocking from the outside. A Windows event is a perfect item for that kind of job: the exported function will start the asynchonous operation by the worker thread and wait on an event which will be set by the worker thread once the work is done. Quite easy to implement without any change in TWSocket. btw: If you really want to do something like you have show, do NOT loop on the state property value but use the events and your own application level state variable. TWSocket.State has never been intended for waiting on a given state. It has been designed for internal use and for informational purpose only. Events are the way to go to trigger state change into your own finite state machine related to your own application. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Creatively annoying a host
> *Subject:* Re: [twsocket] Creatively annoying a host > > I could leave the connection open without sending a response? > > > Just delay the answer for a couple second, this will slow down the > probing. I think keeping the client connection open as long as possible, sending random HTTP headers every few seconds is the best way of slowing down the hacker's crawler. A blacklist just saves a few 404s on each server, but really needs to be implemented at firewall level to stop multiple servers being accessed. One thing that is surprising about these PHP hacks is one domain being targeted was only registered three weeks ago and is on my shared server so can only be accessed by host name, not IP address, yet they've found it already, from Korea. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Suggestion: set FLastError on session connect/disconnect
2Arno: >No problem to use async in a DLL, have a look at OverbyteIcsDll1 demo, >it shows a multi-thread capable implementation. If you don't need MT >have a look at the console demos, those with "con" in name, the same >princple works in a DLL as well. Thanks! I digged into OverbyteIcsDll1 demo and got a question. I see that in DLL demo the thread is responsible for message processing. But what if I don't need a thread? I tryed with while .. do MessagePump but noticed that it processes even the messages of the host app! So no sync here. I suspect console demo approach won't work for me too (am I right?) 2Francois: >If you need to export synchronous functions out of your DLL, I would suggest >using a thread >withing the DLL, having his own message ump and working purely >asynchronoulsy as ICS does so well. Then the exported function will talk to >this thread using traditional multithread synchonization mechanisms to looks >blocking from the outside. A Windows event is a perfect item for that kind >of job: the exported function will start the asynchonous operation by the >worker thread and wait on an event which will be set by the worker thread >once the work is done. Quite easy to implement without any change in TWSocket. Yeah, I guess it's the only way. I have to create separate thread or a socket would process host app events while waiting. I'll consider DoneFlag or even Events to easily implement waiting. >If you really want to do something like you have show, do NOT loop on >the state property value but use the events and your own application level >state variable. TWSocket.State has never been intended for waiting on a >given state. Hmm you mean State isn't reliable? But why? -- Anton -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Creatively annoying a host
>I could leave the connection open without sending a response? You may delay it for, say, 5 sec. But then I guess the vulnerability to DDOS increases (thousands of connections simultaneously). I'm not sure how much of them is possible. >Or send a vast amount of rubbish data in response? Maybe — if you have unlimited outgoing traffic. But no chances that scanner software would catch all of the rubbish sent. It could abort the connection after some amount of data received and leave your server sending something to nowhere. -- Anton -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Suggestion: set FLastError on session connect/disconnect
2Arno: No problem to use async in a DLL, have a look at OverbyteIcsDll1 demo, it shows a multi-thread capable implementation. If you don't need MT have a look at the console demos, those with "con" in name, the same princple works in a DLL as well. Thanks! I digged into OverbyteIcsDll1 demo and got a question. I see that in DLL demo the thread is responsible for message processing. But what if I don't need a thread? I tryed with while .. do MessagePump but noticed that it processes even the messages of the host app! So no sync here. I suspect console demo approach won't work for me too (am I right?) If you don't created a thread with his own message pump, then you rely on the host application which may or may not have a message pump and may do stranges things with his message handling. You get the best isolation from the host application by creating a worker thread and run most of your code in the context of this thread. 2Francois: If you need to export synchronous functions out of your DLL, I would suggest using a thread withing the DLL, having his own message ump and working purely asynchronoulsy as ICS does so well. Then the exported function will talk to this thread using traditional multithread synchonization mechanisms to looks blocking from the outside. A Windows event is a perfect item for that kind of job: the exported function will start the asynchonous operation by the worker thread and wait on an event which will be set by the worker thread once the work is done. Quite easy to implement without any change in TWSocket. Yeah, I guess it's the only way. I have to create separate thread or a socket would process host app events while waiting. I'll consider DoneFlag or even Events to easily implement waiting. If you really want to do something like you have show, do NOT loop on the state property value but use the events and your own application level state variable. TWSocket.State has never been intended for waiting on a given state. Hmm you mean State isn't reliable? But why? State is reliable, but only from the event handlers, not at anytime as seen from the outside. This is how Windows event handling is working: the state variable is updated inside an event hanlder and that event handler may execute code before exiting. The safer way to access the state variable is a the point where the component user is at control: during the event handlers he has installed. Antoher way to consider this is that you have two asynchronous processes (Those are not processes in the sense they are defined within Windows): TWSocket code and your own code. The link between the two process have been designed to work at specific spot in time : when the component triggers an event. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- Anton -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Creatively annoying a host
>I could leave the connection open without sending a response? You may delay it for, say, 5 sec. But then I guess the vulnerability to DDOS increases (thousands of connections simultaneously). I'm not sure how much of them is possible. Well, this is possible, depending on how their are organized. Angus could count the number of simultaneous connection and add trhe delay only if this is below a level he select according to his server configuration. One thousand of delayed connections is probably not an issue at all. Or send a vast amount of rubbish data in response? Maybe — if you have unlimited outgoing traffic. But no chances that scanner software would catch all of the rubbish sent. It could abort the connection after some amount of data received and leave your server sending something to nowhere. You are right, probably the scanner would simply throw away any data and probably close the connection. If the connection is not close, then data sent by Angus will at least use bandwidth at their side (as well as at Angus side). -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Suggestion: set FLastError on session connect/disconnect
>You get the best isolation from >the host application by creating a worker thread and run most of your code >in the context of this thread. Okay, I think I got the structure which seems correct. As I need several sockets for several purposes, I can't use socket's message loop (I don't want to create all of them on DLL load). And I export several functions each of them uses its own socket. TSocketThread GetSocket(channel: TChannel) * return appropriate socket (create and init it if necessary, attach to the thread with ThreadAttach - I can't create them inside Execute because it's more complicated with my design). Execute() cycle while not terminated * WaitFor activate event (to avoid socket events outside the DLL functions — or maybe I just may pause all the sockets?) * do message loop TCommSocket InitConnection() * connect if closed, WaitFor connection event (set in SessionConnected/Closed/Timeout/... handlers) * send some init stuff Communicate() * send request * WaitFor reply received event (set in DataAvail/SessionClosed/Timeout/... handlers) DLLDoCommunicate * GetSocket * set thread's activate event (or resume socket?) * InitConnection * Communicate * process the received data * unset thread's activate event (or pause socket?) Questions are: 1) How to avoid socket events outside the DLL functions (I guess pausing/resuming the sockets is better cause I'll only have one active socket at a time — the one I need) 2) Do I have to do socket.ThreadDetach on app closing or it's OK? -- Anton -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Suggestion: set FLastError on session connect/disconnect
>You get the best isolation from the host application by creating a worker thread and run most of your code in the context of this thread. Okay, I think I got the structure which seems correct. As I need several sockets for several purposes, I can't use socket's message loop (I don't want to create all of them on DLL load). And I export several functions each of them uses its own socket. A single thread is able to handle a lot of sockets (I have applications handling hundreds of sockets per thread). I think you should use only one thread for all socket operation within your application and one thread for each lengthy processing/computation you have to do. The rule is to avoid lengthy processing within the thread doing communication. * return appropriate socket (create and init it if necessary, attach to the thread with ThreadAttach - I can't create them inside Execute because it's more complicated with my design). In my opinion, you should revise you design to better fit the programming model used for ICS. Otherwise you'll end up with a complex application difficult to maintain a prone to errors. to avoid socket events outside the DLL functions — or maybe I just may pause all the sockets? Sockets events are always triggered in the context you the thread having created the socket or the trheaded haing the socket "attached". You should probably not call host application code from another thread than the one active at the time of the call to your DLL. This require some inter-thread communication and synchronization. This will result of more complex code in your DLL with the advantage of maximum isolation of the hosting application. This is important if you have no control on the hosting application and you don't know how it is working internally. Questions are: 1) How to avoid socket events outside the DLL functions (I guess pausing/resuming the sockets is better cause I'll only have one active socket at a time — the one I need) See above. Pausing/resuming the socket shouldn't be used, specially if you have your own worker thread. Just have the socket event handler blocked waiting for some synchronization object. 2) Do I have to do socket.ThreadDetach on app closing or it's OK? Yes, you have to detach the socket from the worker thread before destroying the socket. As I said before, you can avoid thread Attach/detach with careful design. Having to use attached/detach is the sign of a too complex design. Always apply the KIS principle (Keep It Simple). -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Suggestion: set FLastError on session connect/disconnect
>I think you should use only one thread for all socket operation within your application and one thread for each lengthy processing/computation you have to do. The rule is to avoid lengthy processing within the thread doing communication. Yes, that's exactly I intended to do except I don't need long processing so just a single thread inside DLL for socket message loop >In my opinion, you should revise you design to better fit the programming model used for ICS. Otherwise you'll end up with a complex application difficult to maintain a prone to errors. Well, I can't imagine something else without complicating the structure. I need several functions to sync-ly communicate thru sockets. So WaitFor-s and again WaitFor-s... >See above. Pausing/resuming the socket shouldn't be used, specially if you have your own worker thread. Just have the socket event handler blocked waiting for some synchronization object. You mean blocking the entire message loop? I'll implement it myself without using socket method as I don't know what set of sockets would exist. >Yes, you have to detach the socket from the worker thread before destroying the socket. Got it! >As I said before, you can avoid thread Attach/detach with careful design. Having to use attached/detach is the sign of a too complex design. Another ways to reach comatibility between sync and async is are ugly (Synchronize) or complicated (SendMessage or smth else). I'll try with attach/detach -- Anton -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Suggestion: set FLastError on session connect/disconnect
See above. Pausing/resuming the socket shouldn't be used, specially if you have your own worker thread. Just have the socket event handler blocked waiting for some synchronization object. You mean blocking the entire message loop? Yes, indeed. If you don't want any socket event while outside of an exported fDLL function call, then it is enough to block the thread message pump which is only used for socket handling. This would effectively block any socket activity - and of course any event - when not in the context of a called function. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] Hang in TIcsWndControl.ProcessMessages
Hi Everyone Does anyone have ideas why TIcsWndControl.ProcessMessages could hang sometimes when socket is used in separate thread? -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Hang in TIcsWndControl.ProcessMessages
Does anyone have ideas why TIcsWndControl.ProcessMessages could hang sometimes when socket is used in separate thread? Have you followed the rules: create TWSocket within the thread's execute method OR call ThreadAttach ? -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Hang in TIcsWndControl.ProcessMessages
>> Does anyone have ideas why TIcsWndControl.ProcessMessages could >> hang sometimes when socket is used in separate thread? >Have you followed the rules: create TWSocket within the thread's execute >method OR call ThreadAttach ? Yes socket is created within threads execute method, and it works most of the time. I call it after calling shutdown like this, could it be related? FSocket.Shutdown(SD_BOTH); -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
