Re: [twsocket] ASyncReceive and wsoNoReceiveLoop
Jake Traynham wrote: So, it seems that for every time ASyncReceive looped, there would still be a message (FD_Read??) being put in the queue to call it again, which would call my DataAvailable event again, but there wouldn't be any data to read because ASyncReceive had already looped to get all the data. That's correct, it's the call to WSocket_Synchronized_ioctlsocket() with option FIONREAD that causes winsock to send the extra FD_READ message. So nothing is corrupted, simply add wsoNoReceiveLoop to the options to get rid of that behaviour. Winsock will always send subsequent FD_Read messages after any call to one of the receive functions if there is still data available. Should there have only been one FD_Read in the queue initially which would start the ASyncReceive loop but some how the queue is getting corrupted (by some call to ProcessMessages maybe) causing it to respond to the FD_Read more than once. See above. Or should there be an FD_Read for every block of data coming from the server, and if that's the case, why does ASyncReceive loop? Because if there is an FD_Read for every block of data, then ASyncReceive and any DataAvailable events would be called multiple times. There is no relationship to the amount of data, there should be one FD_Read message as long as data is available in winsock's receive buffer. Looping in ASyncReceive is required before closing the socket in order to not miss any pending data. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- 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] Exceptions ignored in OnDataAvailable method
Hello: In the TWSocket component, I've noticed that if an exception is thrown within an OnDataAvailable handler (which is triggered from TCustomWSocket.ASyncReceive() method) they will be ignored, and only the bMore flag is set to false which will stop the receive loop. Since the event delegate performs some background stuff before triggering the event, shouldn't the Exception block call HandleBackGroundException() to trigger OnBgException and give a chance to the application to respond and abort the connection? dZ. -- DZ-Jay [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- 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] ASyncReceive and wsoNoReceiveLoop
Hello Jake, attempt to do a Receive, which would return -1 along with the Would Block winsock error. You don't have to handle GetLastError. Just check the Error argument in every event. The 'Would block' thing is internally handled by TWSocket. If Receive returns 0 or -1 then just exit the event handler. This is normal behavour. if the server sent 6 blocks of data, my DataAvailable event would get called 6 times to receive all of the data No. It is not predictable how many times. TCP does not respect packet boundary, so if the server sends 6 blocks of data you may have 1 time receiving all, or you may have a dozain of small data packets as whell, or part of next or whatever. This is normal behavour of TCP. Eventually you can use LineMode, then TWSocket will take care of it and only will fire OnDataAvailable if LineEnd character(s) are received. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Wednesday, November 28, 2007, 21:24, Jake Traynham wrote: Hello all, I'm using ICS version 6.06 with Turbo C++ Explorer 2006. I had been fighting a problem where my DataAvailable event was being called twice as many times (minus 1) as actually needed. Since I've been using the ICS components for many, many years now, I obviously started looking to see if somehow I was calling ProcessMessages again within the DataAvailable. I couldn't find any where that was true. I finally looked into the TWSocket sources to see where DataAvailable was triggered from and to see if anything there would make it act this way. This is when I saw this wsoNoReceiveLoop thing (which is apparently off by default). Turning that option on made my problem go away. My question is, what am I missing? Either I don't understand why you would *want* ASyncReceive to loop, or maybe I'm not correctly reading in the data? The component I'm working on receives large amounts of data from a server in successive blocks. From what I observed, my DataAvailable event was being called twice minus one more times than it needed to be. For example, if the server sent 6 blocks of data, my DataAvailable event would get called 6 times to receive all of the data, then get called 5 more times. In the 5 extra times, my code would attempt to do a Receive, which would return -1 along with the Would Block winsock error. So, it seems that for every time ASyncReceive looped, there would still be a message (FD_Read??) being put in the queue to call it again, which would call my DataAvailable event again, but there wouldn't be any data to read because ASyncReceive had already looped to get all the data. Again, am I missing something here? Should there have only been one FD_Read in the queue initially which would start the ASyncReceive loop but some how the queue is getting corrupted (by some call to ProcessMessages maybe) causing it to respond to the FD_Read more than once. Or should there be an FD_Read for every block of data coming from the server, and if that's the case, why does ASyncReceive loop? Because if there is an FD_Read for every block of data, then ASyncReceive and any DataAvailable events would be called multiple times. Help! :) Jake -- Jake Traynham Owner, CNS Plug-ins http://www.cnsplug-ins.com/ -- 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] TWSocketServer and backlog
Wait, I'm sorry, I perhaps did not explain correctly: It was taking 5 to 7 minutes for the server to *process* the client's request to completion, not the connection. My tests, although quick and dirty, are intended to check the behaviour of my application as a whole, not just the connection. For the sake of understanding, here's a brief explanation of my project: Its an e-mail queue server; it has a listening thread running TWSocketServer, which will receive requests from my queue client. The client communicates with a custom line-based protocol, and sends the message data, which will then be stored in the queue (filesystem) by the listening thread. A separate thread periodically scans the queue directories and dispatches the messages to the SMTP server. The client builds and encodes the entire message on the fly, line by line as the data is sent, to avoid having the entire thing on memory at once. But that's not really important to this discussion (I'm just proud of it :). A large message may take a few seconds to transmit. My tests all send the same message: a multi-part message with alternative text and html parts, and a small (4Kb) binary attachment, encoded in MIME. The whole thing was about 14Kb (I think, I'm not sure). I was sending 1000 of these. 1. What kind of machine is it? Commodore 64? TS-1000? TRS-80? Just kidding... ;) He, he, he. If it was processing 1000 *connections* in 5 minutes, I'd say a pocket calculator! 2. Is your client class on the server initiating a bunch of additional processes, like database lookups or something? Not the client, but the server is performing some integrity checks, file IO, and eventually storing a record of the transaction in the database. The client does indeed build the message on the fly, even encoding all content as lines are sent to the server (I'm sorry, there I go again, but I think this is pretty nifty :), but it doesn't start doing that until after the connection is established and the message data is going to be sent. Plus both the server and the client were running on the same development machine, along with Delphi-hog-my-memory-2006, in debug mode, with no optimizations. Moreover, the client test app has a TMemo, displaying the progress, and in my rush to make a quick and dirty test, the test app does not free the client objects (all 1000 of them), until it finishes. So the slowness wasn't unexpected. The point of my previous message was to show the difference between two tests, when the only variable was the backlog value: a backlog of 5 took less than half the time to do the exact same work as a backlog of 500. The problem that I see is that the TWSocketServer seems to be taking too long (relatively speaking) to accept the connections. My client seems to be able to send lots of connection requests before a single one is established, thus abusing and exceeding the backlog queue. Of course, it could be my application that is preventing TWSocketServer from doing its work effectively, and if so, then perhaps I should consider using a multi-threaded server. I cringe at that thought, though, because I had so many problems getting TWSocketThrdServer to run properly (due to my own lack of experience with this sort of thing). Any recommendations would be greatly appreciated. dZ. On Nov 28, 2007, at 18:47, Hoby Smith wrote: H... If it is taking your system 5 to 7 MINUTES to process 1000 connect / disconnect cycles, then something is very wrong. I would have to rerun my tests, but I am thinking that I was doing 1K connect / disconnects in about 10 to 15 seconds when running both server and client on a single core P4. Perhaps a little faster using several client instances at the same time, although the performance maxed quickly on a single core CPU. I believe it was much faster on a 4 way Xeon machine I tested it on. I can get more specific stats for you, if you want them. But, whatever my specific results were, 5 to 7 MINUTES is just WAY off. 1. What kind of machine is it? Commodore 64? TS-1000? TRS-80? Just kidding... ;) 2. Is your client class on the server initiating a bunch of additional processes, like database lookups or something? 3. Do you have any problems with other apps on your system running slow? Perhaps you have a bad driver or resource conflict with your NIC? Just some thoughts... Hoby -- DZ-Jay [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- 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] TWSocketServer and backlog
On Nov 29, 2007, at 06:10, Wilfried Mestdagh wrote: Hello DZ-Jay, So conclusion is that increasing the backlog does: - decrease the performance for accepting connections - decrease the overall performance of the application This seems to be the conclusion of mine and Huby's tests. Also: - connecting clients should have a range of retry's when refused, eventually with a random small delay. Agreed. For your application: Seems you have a lot of processing to do. While your code is executing no incoming socket can be accepting. Then maybe execute a certain block (the most time consuming one) in a separate thread ? You can exchange data between threads the most easy is by posting a message where a pointer to the data is in WParam argument. The pointer can be freed in the custom message handler. I will consider this. Thank you, Wilfried. However, the queue manager (listening) thread does not have a single large block of long-executing code, but very small blocks that each do a little work, which may be affecting performance: 1. It runs TWSocketServer, so it has to process all incoming connections and client communications. 2. For each client, it parses the incoming requests from the client to determine what needs to be done, and which state they are in. The request is a string in CMD:VALUE fomat. 3. If it's message data, it writes to the filesystem. 4. When done successfuly, it logs to the database. 5. When a message posted by the dispatcher thread announces that a message has been dispatched, the manager thread needs to log this to the database. And all throughout it is writing to a log file (at least while debugging), which needs to be synchronized among all threads. I will try to do some analysis to determine which portions are the bottleneck and see if they could be offset to a separate thread. I do not mind too much right now if the server runs a little slow; we can always re-factor it and optimize it in the future. But what I would like to avoid is rejecting connections too often because of a full backlog (which seems to be happening right now). Perhaps I should run the TWSocketServer on its own thread, and post messages from the clients to the queue manager thread to do the work? Although this seems too complex and expensive. It almost looks like each client should run on its own thread... :( dZ. -- DZ-Jay [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- 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] Trying to do some old stuff
Hi All... This in regards to ICS V5. I think... I wish to do some legacy stuff, involving Delphi1 (!!) I'd like to implement a simple UDP conversation, to link an old Win16 app, to a new Win32 only driver via the LocalHost. (I sort of understand this way of doing things, I most defiantely do not understand Thunking, and my C is worse than not good.) Oh yes, this is for my own personal use, an old Win3.11 program I made many years ago, that uses DLLs to interface to hardware. Trouble is, WinNT (2000) does not allow that sort of thing, direct port access, and as it'd be good to have the app running on one machine, talking to ports etc on another one on my LAN, like I have later Win32 stuff, I thought of doing a UDP peer-2-peer thing. I already have UDP stuff working that way between other app's and PC's in the Win32 world. Trouble is, I no longer have readable sources, they are all on 5 1/4 360k floppies! And the only person I know who has old hardware like that, says that the disks are unreadable, Otherwise I'd rework it in D7. However I seem to be having a little trouble getting ICS installed into the D1 IDE. I edited the IcsDel1.bat file in \ICS\Delphi1 to represent the actual paths used on this system. But when I run it, it does this C:\D_32\ICS\Delphi1IcsDel1 The device is not ready.[ Huh ? ] Delphi Compiler Version 8.0 Copyright (c) 1983,95 Borland International C:\D_32\ICS\DELPHI\VC32\ICSDEFS.INC(443) C:\D_32\ICS\DELPHI\VC32\ICSDEFS.INC(443) C:\D_32\ICS\DELPHI\VC32\WSOCKBUF.PAS(255) C:\D_32\ICS\DELPHI\VC\WINSOCK.PAS(640) C:\D_32\ICS\DELPHI\VC32\WSOCKET.PAS(7378) CliDemo1.pas(279) CLIDEMO.DPR(12) Error 164: Duplicate resource identifier (CLIDEMO.RES). Compile error C:\D_32\ICS\Delphi1 I also have D7 installed on this PC, is that conflicting? Looking at the Version 8.0 announcement... So what have I done wrong? I did get it installed and working in D7 with no problem. D1 is fully functional on here too, there don't seem to be any clashes that I know of. Oh yes, the PC, Win XP Pro, all updates etc... The target machine run's Win2k. The IcsDel1.bat file is like this... @echo off REM * * * * * * * * * * * * * * * * * * * * * * * * * * * REM * * REM * ICS - Internet Component Suite* REM * * REM * Delphi 1 automated construction V1.00 * REM * (c) 1997-2000 by Francois PIETTE * REM * http://www.rtfm.be/fpiette/indexuk.htm* REM * [EMAIL PROTECTED] [EMAIL PROTECTED] * REM * * REM * You must change PATH, DELPHI_PATH and ICS_PATH* REM * below to fit your system. * REM * * REM * Remember to install all components in Delphi 1 ! * REM * Remember to use Delphi 1 to open all forms and* REM * ignore Font.CharSet and OldCreateOrder properties * REM * * REM * * * * * * * * * * * * * * * * * * * * * * * * * * * SET DELPHI_PATH=C:\D1\DELPHI SET ICS_PATH=C:\D_32\ICS PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;%DELPHI_PATH%\BIN echo /cwdcc.cfg echo /mdcc.cfg echo /r%DELPHI_PATH%\LIB dcc.cfg echo /u%DELPHI_PATH%\LIB dcc.cfg echo /i%DELPHI_PATH%\LIB dcc.cfg echo /E%ICS_PATH%\DELPHI1 dcc.cfg echo /O%ICS_PATH%\DELPHI1 dcc.cfg echo /I%ICS_PATH%\DELPHI\VCdcc.cfg echo /I%ICS_PATH%\DELPHI\VC32 dcc.cfg echo /I%ICS_PATH%\DELPHI\INTERNET dcc.cfg echo /R%ICS_PATH%\DELPHI\VCdcc.cfg echo /R%ICS_PATH%\DELPHI\VC32 dcc.cfg echo /R%ICS_PATH%\DELPHI\INTERNET dcc.cfg echo /U%ICS_PATH%\DELPHI\VCdcc.cfg echo /U%ICS_PATH%\DELPHI\VC32 dcc.cfg echo /U%ICS_PATH%\DELPHI\INTERNET dcc.cfg d: cd %ICS_PATH%\delphi\internet call ..\..\delphi1\dcc1 clidemo if errorlevel 1 goto error call ..\..\delphi1\dcc1 client5 if errorlevel 1 goto error call ..\..\delphi1\dcc1 client7 if errorlevel 1 goto error call ..\..\delphi1\dcc1 dnslook if errorlevel 1 goto error call ..\..\delphi1\dcc1 dynCli if errorlevel 1 goto error call ..\..\delphi1\dcc1 finger if errorlevel 1 goto error call ..\..\delphi1\dcc1 ftpserv if errorlevel 1 goto error call ..\..\delphi1\dcc1 ftptst if errorlevel 1 goto error call ..\..\delphi1\dcc1 httpasp if errorlevel 1 goto error call ..\..\delphi1\dcc1 httpasy if errorlevel 1 goto error call ..\..\delphi1\dcc1 httpchk if errorlevel 1 goto error call ..\..\delphi1\dcc1 httpdmo if errorlevel 1 goto error call ..\..\delphi1\dcc1 httpget if errorlevel 1 goto error call ..\..\delphi1\dcc1 httppg if errorlevel 1 goto error call ..\..\delphi1\dcc1 httptst if errorlevel 1 goto error call ..\..\delphi1\dcc1 mailrcv if errorlevel 1 goto error call ..\..\delphi1\dcc1 mailrob if errorlevel 1 goto error call
Re: [twsocket] TWSocketServer and backlog
DZ-Jay wrote: On Nov 29, 2007, at 06:10, Wilfried Mestdagh wrote: Hello DZ-Jay, So conclusion is that increasing the backlog does: - decrease the performance for accepting connections - decrease the overall performance of the application This seems to be the conclusion of mine and Huby's tests. Strange, I never noticed something like that. You can exchange data between threads the most easy is by posting a message where a pointer to the data is in WParam argument. The pointer can be freed in the custom message handler. That's indeed the fastest way since the thread must not wait. Perhaps I should run the TWSocketServer on its own thread, and post messages from the clients to the queue manager thread to do the work? Although this seems too complex and expensive. It almost looks like each client should run on its own thread... :( I'm that sure: 1 - Stressing a server with 100 connection attempts per second is most likely not a real world scenario, except upon DoS attacks. 2 - Run your stress tester against IIS or other servers, I found that they were not able to accept more clients per second than my server. 3 - I played with different designs. a) Listening sockets in one thread, client sockets in another thread(s). This introduces a new problem, clients are accepted very fast, however the listening thread must synchronize with the client thread(s) which may take longer than with current TWSocketServer, I worked around by posting just the socket handle to the thread which was fast, however also rather complicated to handle all the client stuff/pool in the threads. b) Listening sockets in one thread, one thread per client. AFAIR without a thread pool accepting clients was slower than with TWSocketServer. c) I even hacked together a server that used M$ overlapped sockets, this was a rather disapointing discourse since performance was the same as with (a). The goal is to accept clients as fast as possible, once they are connected it won't hurt to let them wait some milliseconds. Before you rewrite your application I suggest you code some test apps. with different designs and compare their performance. -- Arno Garrels dZ. -- DZ-Jay [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- 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] TWSocketServer and backlog
--- Original Message --- From: Arno Garrels[mailto:[EMAIL PROTECTED] You can exchange data between threads the most easy is by posting a message where a pointer to the data is in WParam argument. The pointer can be freed in the custom message handler. That's indeed the fastest way since the thread must not wait. However, if the main thread notified the slave threads to quit, the last thread that quits may post messages (before receiving the WM_QUIT message) to the first one and fail, which will cause the memory in the message to not be freed (until the application finally quits). I don't know if this is a real concern, though. 1 - Stressing a server with 100 connection attempts per second is most likely not a real world scenario, except upon DoS attacks. I agree. However, this is very easily done by a brain-dead developer using my queue client class in a simple 'for' loop to send a lot of messages at once, say, an announcement to all our customers. I would like to prevent this as much as possible by improving connection acceptance speed on the server, or else I'll have to cripple the client somehow. Do not underestimate the tenacity of morons. :) 2 - Run your stress tester against IIS or other servers, I found that they were not able to accept more clients per second than my server. I'm sure this is true. I am able to avoid the whole issue by responsibly designing the client application: send the next connection request after the first one triggers OnSessionConnected, or connecting only a few clients at a time, then pause until they are done. This not only improves performance of the server, but it prevents an inadvertent DoS attack from an application that needs to send lots of messages at once. 3 - I played with different designs. Which would you consider to work best? The goal is to accept clients as fast as possible, once they are connected it won't hurt to let them wait some milliseconds. This is indeed my goal. Would it make sense to have a pool of listening sockets in a separate (single) thread that will post a message to the (single) working thread with the socket handle? That way the connections can be established quickly, and my server can continue doing its processing within a single thread so that I don't have to redesign it right now. -dZ. Sent: 11/29/2007 1:52:38 PM To : twsocket@elists.org Cc : Subject : RE: Re: [twsocket] TWSocketServer and backlog DZ-Jay wrote: On Nov 29, 2007, at 06:10, Wilfried Mestdagh wrote: Hello DZ-Jay, So conclusion is that increasing the backlog does: - decrease the performance for accepting connections - decrease the overall performance of the application This seems to be the conclusion of mine and Huby's tests. Strange, I never noticed something like that. Perhaps I should run the TWSocketServer on its own thread, and post messages from the clients to the queue manager thread to do the work? Although this seems too complex and expensive. It almost looks like each client should run on its own thread... :( I'm that sure: 1 - Stressing a server with 100 connection attempts per second is most likely not a real world scenario, except upon DoS attacks. 2 - Run your stress tester against IIS or other servers, I found that they were not able to accept more clients per second than my server. 3 - I played with different designs. a) Listening sockets in one thread, client sockets in another thread(s). This introduces a new problem, clients are accepted very fast, however the listening thread must synchronize with the client thread(s) which may take longer than with current TWSocketServer, I worked around by posting just the socket handle to the thread which was fast, however also rather complicated to handle all the client stuff/pool in the threads. b) Listening sockets in one thread, one thread per client. AFAIR without a thread pool accepting clients was slower than with TWSocketServer. c) I even hacked together a server that used M$ overlapped sockets, this was a rather disapointing discourse since performance was the same as with (a). The goal is to accept clients as fast as possible, once they are connected it won't hurt to let them wait some milliseconds. Before you rewrite your application I suggest you code some test apps. with different designs and compare their performance. -- Arno Garrels dZ. -- DZ-Jay [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- 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] Trying to do some old stuff
VC32 folder is for 32 bit. use VC folder in D1 path. -- [EMAIL PROTECTED] The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be - Original Message - From: Dave Baxter [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Thursday, November 29, 2007 6:31 PM Subject: [twsocket] Trying to do some old stuff Hi All... This in regards to ICS V5. I think... I wish to do some legacy stuff, involving Delphi1 (!!) I'd like to implement a simple UDP conversation, to link an old Win16 app, to a new Win32 only driver via the LocalHost. (I sort of understand this way of doing things, I most defiantely do not understand Thunking, and my C is worse than not good.) Oh yes, this is for my own personal use, an old Win3.11 program I made many years ago, that uses DLLs to interface to hardware. Trouble is, WinNT (2000) does not allow that sort of thing, direct port access, and as it'd be good to have the app running on one machine, talking to ports etc on another one on my LAN, like I have later Win32 stuff, I thought of doing a UDP peer-2-peer thing. I already have UDP stuff working that way between other app's and PC's in the Win32 world. Trouble is, I no longer have readable sources, they are all on 5 1/4 360k floppies! And the only person I know who has old hardware like that, says that the disks are unreadable, Otherwise I'd rework it in D7. However I seem to be having a little trouble getting ICS installed into the D1 IDE. I edited the IcsDel1.bat file in \ICS\Delphi1 to represent the actual paths used on this system. But when I run it, it does this C:\D_32\ICS\Delphi1IcsDel1 The device is not ready.[ Huh ? ] Delphi Compiler Version 8.0 Copyright (c) 1983,95 Borland International C:\D_32\ICS\DELPHI\VC32\ICSDEFS.INC(443) C:\D_32\ICS\DELPHI\VC32\ICSDEFS.INC(443) C:\D_32\ICS\DELPHI\VC32\WSOCKBUF.PAS(255) C:\D_32\ICS\DELPHI\VC\WINSOCK.PAS(640) C:\D_32\ICS\DELPHI\VC32\WSOCKET.PAS(7378) CliDemo1.pas(279) CLIDEMO.DPR(12) Error 164: Duplicate resource identifier (CLIDEMO.RES). Compile error C:\D_32\ICS\Delphi1 I also have D7 installed on this PC, is that conflicting? Looking at the Version 8.0 announcement... So what have I done wrong? I did get it installed and working in D7 with no problem. D1 is fully functional on here too, there don't seem to be any clashes that I know of. Oh yes, the PC, Win XP Pro, all updates etc... The target machine run's Win2k. The IcsDel1.bat file is like this... @echo off REM * * * * * * * * * * * * * * * * * * * * * * * * * * * REM * * REM * ICS - Internet Component Suite* REM * * REM * Delphi 1 automated construction V1.00 * REM * (c) 1997-2000 by Francois PIETTE * REM * http://www.rtfm.be/fpiette/indexuk.htm* REM * [EMAIL PROTECTED] [EMAIL PROTECTED] * REM * * REM * You must change PATH, DELPHI_PATH and ICS_PATH* REM * below to fit your system. * REM * * REM * Remember to install all components in Delphi 1 ! * REM * Remember to use Delphi 1 to open all forms and* REM * ignore Font.CharSet and OldCreateOrder properties * REM * * REM * * * * * * * * * * * * * * * * * * * * * * * * * * * SET DELPHI_PATH=C:\D1\DELPHI SET ICS_PATH=C:\D_32\ICS PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;%DELPHI_PATH%\BIN echo /cwdcc.cfg echo /mdcc.cfg echo /r%DELPHI_PATH%\LIB dcc.cfg echo /u%DELPHI_PATH%\LIB dcc.cfg echo /i%DELPHI_PATH%\LIB dcc.cfg echo /E%ICS_PATH%\DELPHI1 dcc.cfg echo /O%ICS_PATH%\DELPHI1 dcc.cfg echo /I%ICS_PATH%\DELPHI\VCdcc.cfg echo /I%ICS_PATH%\DELPHI\VC32 dcc.cfg echo /I%ICS_PATH%\DELPHI\INTERNET dcc.cfg echo /R%ICS_PATH%\DELPHI\VCdcc.cfg echo /R%ICS_PATH%\DELPHI\VC32 dcc.cfg echo /R%ICS_PATH%\DELPHI\INTERNET dcc.cfg echo /U%ICS_PATH%\DELPHI\VCdcc.cfg echo /U%ICS_PATH%\DELPHI\VC32 dcc.cfg echo /U%ICS_PATH%\DELPHI\INTERNET dcc.cfg d: cd %ICS_PATH%\delphi\internet call ..\..\delphi1\dcc1 clidemo if errorlevel 1 goto error call ..\..\delphi1\dcc1 client5 if errorlevel 1 goto error call ..\..\delphi1\dcc1 client7 if errorlevel 1 goto error call ..\..\delphi1\dcc1 dnslook if errorlevel 1 goto error call ..\..\delphi1\dcc1 dynCli if errorlevel 1 goto error call ..\..\delphi1\dcc1 finger if errorlevel 1 goto error call ..\..\delphi1\dcc1 ftpserv if errorlevel 1 goto error call ..\..\delphi1\dcc1 ftptst if errorlevel 1 goto error call ..\..\delphi1\dcc1 httpasp if errorlevel 1
Re: [twsocket] TWSocketServer and backlog
[EMAIL PROTECTED] wrote: --- Original Message --- From: Arno Garrels[mailto:[EMAIL PROTECTED] You can exchange data between threads the most easy is by posting a message where a pointer to the data is in WParam argument. The pointer can be freed in the custom message handler. That's indeed the fastest way since the thread must not wait. However, if the main thread notified the slave threads to quit, the last thread that quits may post messages (before receiving the WM_QUIT message) to the first one and fail, which will cause the memory in the message to not be freed (until the application finally quits). I don't know if this is a real concern, though. When the process died the memory is given back to the OS anyway, so no problem. PostMessage() will return False on failure, in this case the memory can be released by the calling thread. 1 - Stressing a server with 100 connection attempts per second is most likely not a real world scenario, except upon DoS attacks. I agree. However, It's easy to DoS any server ;-) 2 - Run your stress tester against IIS or other servers, I found that they were not able to accept more clients per second than my server. I'm sure this is true. 3 - I played with different designs. Which would you consider to work best? Hard to tell, a good compromise is using TWSocketServer given any lengthy task is run in worker threads. I think separating socket IO work from other tasks by using worker threads for those tasks considered lengthy is the way to go. The definition of lengthy however is another story then. g -- Arno Garrels -dZ. Sent: 11/29/2007 1:52:38 PM To : twsocket@elists.org Cc : Subject : RE: Re: [twsocket] TWSocketServer and backlog DZ-Jay wrote: On Nov 29, 2007, at 06:10, Wilfried Mestdagh wrote: Hello DZ-Jay, So conclusion is that increasing the backlog does: - decrease the performance for accepting connections - decrease the overall performance of the application This seems to be the conclusion of mine and Huby's tests. Strange, I never noticed something like that. Perhaps I should run the TWSocketServer on its own thread, and post messages from the clients to the queue manager thread to do the work? Although this seems too complex and expensive. It almost looks like each client should run on its own thread... :( I'm that sure: 1 - Stressing a server with 100 connection attempts per second is most likely not a real world scenario, except upon DoS attacks. 2 - Run your stress tester against IIS or other servers, I found that they were not able to accept more clients per second than my server. 3 - I played with different designs. a) Listening sockets in one thread, client sockets in another thread(s). This introduces a new problem, clients are accepted very fast, however the listening thread must synchronize with the client thread(s) which may take longer than with current TWSocketServer, I worked around by posting just the socket handle to the thread which was fast, however also rather complicated to handle all the client stuff/pool in the threads. b) Listening sockets in one thread, one thread per client. AFAIR without a thread pool accepting clients was slower than with TWSocketServer. c) I even hacked together a server that used M$ overlapped sockets, this was a rather disapointing discourse since performance was the same as with (a). The goal is to accept clients as fast as possible, once they are connected it won't hurt to let them wait some milliseconds. Before you rewrite your application I suggest you code some test apps. with different designs and compare their performance. -- Arno Garrels dZ. -- DZ-Jay [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- 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
[twsocket] Multi Thread error.
Hello, We have a problem with an application that have 2 threads, when we try to send 2 different messages by 2 thread using 2 instances of twSocket V5.25. Each thread got their own socket connection. If the threads are sending at the same time the application crash with an access violation error. I am using the function sendstr and I notice the str parameter is declare as constant. Then it is convert to a pointer and send to the function PutDataInSendBuffer(Data : Pointer; Len : Integer); . It is possible that the compiler will use only one memory location for the variable str declare in sendstr? Did some one have seen the behaviour ? Thanks Yvan --- J'ai un problème lorsque que je retrouve dans une application 2 THREADS qui envoyer des messages dans des sockets différents. Si les threads envoient un message en même temps en utilisant 2 instances de tWSocket j'obtient un Access violation. J'utilise la fonction SENDSTR pour l'envois du message. Jai cette erreur a la ligne cWritten := oBuffer.Write(Data, Len); dans la fonction PutDataInSendBuffer(Data : Pointer; Len : Integer); Jai remarqué que la fonction sendStr déclare le ses paramètres avec une constance (const Str : String). Celui-ci est acheminé en pointeur a la fonction PutDataInSendBuffer. Est-ce possible que le compilateur garde quune seul espace de mémoire pour cette variable? Est-ce que quelqu'un à déjà vécu cette problématique? Merci Yvan Yvan Boutin [EMAIL PROTECTED] -- 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
