Re: [twsocket] Simultaneous TPing request using multithread.
Absolutely no issue :) I've already written such an application. Works either 32 bit or 64 bit. If you like I can let you have the application plus source code to help give you some ideas where to start. Lester On 02/03/2013 16:00, Marc Gauthier wrote: Good day, I need to build a network monitoring tool that will ping about a 1000 IP's on a regular basis, I plan to use Thread-Pool for this. I know there is an issue with doing simultaneous ICMP request because all the listening socket receive the reply and this create confusion. My question is does ICS Ping component work out-the-box for this, or I need to modify the component and add some unique identifier to the data being sent? Cheers, Marc. -- 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] Wiki issue
This has been noticed before. Bogus accounts get created all the time, but you have to have permission to actually contribute. Those bogus accounts therefore do not harm the system, apart from take up database space. Francois (and I believe some other senior developers) have the power to grant you write rights if you would like to contribute to the Wiki :) Lester On 01/08/2012 18:40, Markus Humm wrote: Hello, I've looked something up in the wiki today and routinely (don't do much ICS related work currently so routinely is months...) I look at the list of latest changes to see how wiki progresses. (Has anybody not yet ontributed? ;-) ) Now I saw that in the last few days 500 bogus user accounts with seemingly random names have been created. Anybody noticed this already? Does this do any harm? Are there any counter measures? (e.g. a log with the IP of those creators and if it's the same IP maybe it can be traced and at least a provide get informed) This is for this time, but I'll most probably return with another thread about TSmtpCli tonight... Greetings Markus -- 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] Fwd: Re: FIN being set to early on HTTP response when serving uTorre
On 12/07/2012 11:47, Angus Robertson - Magenta Systems Ltd wrote: I've fixed my local copy of ICS V8, which version are you using? Currently running icsipv6 (I presume this is ICS v8?). I have today updated from 1046 to 1048 Lester -- 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] Fwd: Re: FIN being set to early on HTTP response when serving uT
Good, yes the ipv6 branch has become V8. I've just updated SVN and the nightly V8 zip file has been updated, a little early. I'm still testing pipelining, discovered Firefox has a command to enable it. Angus -- The changes you have made have resolved the issue I was having - thanks very much :) Lester -- 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] Fwd: Re: FIN being set to early on HTTP response when serving uTorrent web cl
uTorrent is indeed closing the connection, but that's just because the
preceding TCP Packet being sent to from the sever has the flag set to
tell it to do so.
I've done a lot more work since yesterday, and I've managed to find the
cause of the problem! The issue is caused by having a superfluous
carriage return being sent in the HTTP request
Here is a request which will succeed
http://i.imgur.com/8Sjlx.png
Here is a request that will end up in the file ending up being only 8 KB.
http://i.imgur.com/EkrTo.png
It seems that if the request being sent has an extra line feed at the
end, it will cause ICS not to serve the file properly.
I reproduced this using Indy HTTP Client and creating an additional
FHTTP.IOHandler.WriteLn(''); on line 2273 in file IdHTTP.pas
I will write to the software developer (uTorrent) to inform them of the
superfluous carriage return, since it does break HTTP 1.1 RFC, but
still, ICS shouldn't choke as a result of this.
Lester
On 10/07/2012 16:58, Angus Robertson - Magenta Systems Ltd wrote:
When the client is Firefox, there is no issue - the file is loaded
successfully. If the client us uTorrent, then the server is
setting the FIN flag too early, resulting in an incomplete file
acquisition.
Regardless of the file type, content or size, the same amount of
data (exactly 8192 bytes) is being transmitted before the FIN flag
is being set.
The ICS code does not send a FIN flag, that's low level TCP stuff.
How do you know uTorrent is not closing the connection early?
How much logging is your web server application doing, does it show the
entire file sent?
Angus
--
To unsubscribe or change your settings for TWSocket mailing list
please gotohttp://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website athttp://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] FIN being set to early on HTTP response when serving uTorrent web client
Http Server: ICS ipv6 Rev 1046 Http Client 1 - uTorrent 3.2 Http Client 2 - Firefox 13.1 Having an issue where the file stream requested is being terminated early by the HTTP Server, for a specific web client. When the client is Firefox, there is no issue - the file is loaded successfully. If the client us uTorrent, then the server is setting the FIN flag too early, resulting in an incomplete file acquisition. Regardless of the file type, content or size, the same amount of data (exactly 8192 bytes) is being transmitted before the FIN flag is being set. Here is a copy of the HTTP requests and responses from the various clients: uTorrent as http Client GET /yay.png HTTP/1.1 Host: 10.110.176.120 User-Agent: BTWebClient/3200(27568) Accept-Encoding: gzip Connection: Close ICS response: HTTP/1.1 200 OK Content-Type: image/png Content-Length: 17634 Accept-Ranges: bytes Last-Modified: Wed, 20 Jun 2012 10:43:15 GMT Connection: Close Then 8192 bytes and then FIN. Firefox as http Client GET /yay.png HTTP/1.1 Host: 10.110.176.120 User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-gb,en;q=0.5 Accept-Encoding: gzip, deflate Connection: close ICS Response: HTTP/1.1 200 OK Content-Type: image/png Content-Length: 17634 Accept-Ranges: bytes Last-Modified: Wed, 20 Jun 2012 10:43:15 GMT Connection: Close Then 17634 bytes and then FIN. Does anybody have an idea why this might be happening? I am able to provide wireshark traces if required. Lester -- 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] Bug with ICS and PING?
Having an interesting problem with TPing, and the replies under certain circumstances Here is my code I'm using: Ping1.Address := '10.110.12.1'; Memo1.Lines.Add(IntToStr(Ping1.Ping)); Memo1.Lines.Add(IntToStr(Ping1.ErrorCode)); Memo1.Lines.Add(IntToStr(Ping1.Reply.RTT)); If the address 10.110.12.1 Responds, I see the results 1, 0 and then the ms of the reply in my Memo1 - this is good. If the address 10.110.12.1 Does not respond, (DOS PING shows Request timed out) I see the results 0, 11010 and 0 in Memo1 - this is also good. If however you are trying to ping a device on the local subnet which is not there (DOS PING shows Destination host unreachable.) , the application returns 1, 0 and then the Reply.RTT shows the correct time it took to fail. It seems to me that this is a bug because the flag returned from ping indicates a success, and the ErrorCode also indicates no errors. Windows 7 SP1 64 bit Delphi XE2 Update 4 ICS BetaV8 Rev 991 VCL Forms Application -- 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] Bug with ICS and PING?
Are you suggesting that there is no bug? That's fine, but how does one differentiate then from a successful ping and an unsuccessful one (where CMD PING would reply Destination host unreachable.) Lester On 07/05/2012 21:29, François Piette wrote: If however you are trying to ping a device on the local subnet which is not there (DOS PING shows Destination host unreachable.) , the application returns 1, 0 and then the Reply.RTT shows the correct time it took to fail. It seems to me that this is a bug because the flag returned from ping indicates a success, and the ErrorCode also indicates no errors. The success means the ICMP request packet has been sent. -- François Piette -- 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] Bug with ICS and PING?
I've just answered my own question :) There is also TPing.Reply.Status - a zero is good, a non-zero is bad (seemingly). Thanks all. Lester On 07/05/2012 22:01, Lester Clayton wrote: Are you suggesting that there is no bug? That's fine, but how does one differentiate then from a successful ping and an unsuccessful one (where CMD PING would reply Destination host unreachable.) Lester -- 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] Should next ICS version support anything before DelphiXE ?
My opinion prior to Delphi XE2: Yes My opinion after Delphi XE2: No I've been a big fan of Pascal since Turbo Pascal version 4, and I've followed most of Borland/Inprise/Embarcadero since the late 80's. I've purchased various versions of Pascal and Delphi in my life, and I've been a HUGE fan of Delphi 7 Professional since it came out. I made the mistake of buying Delphi 2007, and I've deliberately not bought any more Delphi since XE2 came out. I refused to pay for something that would give me no actual benefit, and I've been one of those people moaning bitterly about lack of 64 bit compiler support. Along comes Delphi XE2 and blows us all away by not only doing 64 bit compiler support, but also with Firemonkey - which gives us the ability to write apps for Mac. This was a huge surprise for me, and a very nice one since I have many apps I would like to port to Mac. Sure, the IDE is buggy as hell, but you just have to work around them and figure out what not to do, and you'll get good results. I understand other people's reluctance to move to Delphi XE2 - especially if they do not need this 64 bit and Mac support - since Delphi 7 is stable, has a great workspace for creating forms, and creates reasonably decent sized EXE's. I would like to see Delphi claw some market share, because finding sample code to work this is tough as nails in comparison with C++. I also have to look at the other side of the coin, and it's quite a lot to ask people to stick with old technology just because it works well. Time is one of our biggest commodities and if we need to spend it trying to ensure code works with old platforms, it could become counter-productive. Lester -- 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] 64 Bit for XE2
Delphi XE2 supports 64 bit compiling. The current release of ICS also supports 64 bit compiling. ICS also has a beta for Firemonkey which will allow you to compile to Mac OSX (32 bit) apps. On 30/03/2012 18:48, pkappet...@charter.net wrote: When will there be 64 bit support for this? -- 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
