Re: [twsocket] Should next ICS version support anything before DelphiXE ?
Still using Delphi 7. -Original Message- From: twsocket-boun...@elists.org [mailto:twsocket-boun...@elists.org] On Behalf Of François Piette Sent: Wednesday, March 28, 2012 8:59 PM To: ICS support mailing Subject: [twsocket] Should next ICS version support anything before DelphiXE ? Hi ! Im planning the next ICS version Being unable to use any features added to Delphi in the last 10 years is very restricted. Maybe we need to cease support for old Delphi versions ? Of course ICS V5 and V7 will remains available however, the only changes will be bug fixes. What do you think ? Please keep your answer as short as possible, I just want to have an idea about how many of you are still using an old Delphi version. -- 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 -- 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 beforeDelphiXE ?
Well I for my part would like see the IP V6 branch of Arno Garrels as the next ICS V8 (with support of older Delphi versions, XE2 firemonkey and x64 bit) because it is a REAL step forward for ICS and useful without new language mumbo jumbo. ;) I'm not saying there might be a time to make a cut and say that's it for now only the current and following Versions of delphi. But come on, IP V6 IS coming and it is big and it will be needed also in legacy applications developed with older Delphi versions. Regards Lars -Original Message- From: twsocket-boun...@elists.org [mailto:twsocket-boun...@elists.org] On Behalf Of Arno Garrels Sent: Wednesday, March 28, 2012 11:00 PM To: ICS support mailing Subject: Re: [twsocket] Should next ICS version support anything beforeDelphiXE ? François Piette wrote: I'm planning the next ICS version. Interesting, I'm planning it since last year as well, namely in the IPv6/FireMonkey beta branch and while porting ICS to XE2 64-bit. What are your actual plans except abandon support for older compilers? Being unable to use any features added to Delphi in the last 10 years is very restricted. Maybe we need to cease support for old Delphi versions ? Abandon Delphi 7 support was just stupid unless someone rewrites ICS to take full advantage of the new and powerful language features at the same time, sorry ( I won't be the guy doing this ). Actually the tweaks required to get current ICS compiled from D7 up to latest RAD Studio version are **very minor** (oh, this property StrictDelimiter doesn't exist in D7? **come on**). BTW: Indy still supports D5! Taking into account that many of the new language features can't be used without problems before XE/2010 (because of bugs), it makes *no sense* at all to abandon D7 if at the same time support for D2007 is kept. It would make sense though to start a _new version from *scratch*, such an incarnation of ICS ;) would then of course support only XE+ or maybe D2010+, is that your plan? -- Arno -- 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 -- 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] Setting additional Header fields depending on the mimetype in the HTTP Server
Well, I simply changed the source code and added a callback. It's normally
not the way to go, but well, sometimes it's the easiest way.
I'm talking about mostly automatically served files so calling
senddocument is out of the question.
Overriding said function would mean, I would have to duplicate the code and
with each update of ICS I would have to check all my projects for this
overriden function. Not very practical. It's easier to change the ICS code
once every update...
Persistant headers are not usefull cause only certain Mimetype need special
headers and as an another use example: the Date header should reflect the
current (GMT) time, not the one when you started the server. With this
callback, you could handle time sensitive headers also.
The best way to go would normally be to implement a callback in the ICS http
server similar to the one which was added not too long ago for the
MimeContentType. :)
And I believe this is not just a special scenario for our apps.
According to Pagespeed and feedback from our users this relative simple
change (Date and Expire headers) improved the response times of the
webserver and the display speed of the pages a lot. Just because all the js
libs, the css and image file are now taken from the cache and not downloaded
every time (IE seem to be a special case, according to the network monitor
of the IE9 the static files get a 304 answer which is in NO way send by ICS
http ;) ).
Lars
-Original Message-
From: twsocket-boun...@elists.org
[mailto:twsocket-boun...@elists.org] On Behalf Of RTT
Sent: Sunday, December 11, 2011 1:18 AM
To: ICS support mailing
Subject: Re: [twsocket] Setting additional Header fields
depending on the mimetype in the HTTP Server
If you call the SendDocument yourself, you can use this
overload version
procedure SendDocument(SendType: THttpSendType; const CustomHeaders:
string); overload; virtual; { V7.29 }
If not, you can override it and pass your custom header in
the CustomHeaders parameter, calling the inherited
SendDocument. This way you don't need to duplicate that function code.
Or you can use the PersistentHeader property. Just fill it
with your custom headers, before the send, and clear after
done if additional sends don't need it anymore.
Hello,
I need to add for certain mime content types special headers to the
HTTP header. As an example for static resources the
Expires or Cache-Control
headers.
Unfortunatly I haven't found a way to do this without
overriding (and
duplicating) the SendDocument function. Did I miss
something obvious
or is there no way to add custom headers depending on the
mime content type?
Thanks
Lars
--
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
--
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] Setting additional Header fields depending on the mimetype in the HTTP Server
Hello, I need to add for certain mime content types special headers to the HTTP header. As an example for static resources the Expires or Cache-Control headers. Unfortunatly I haven't found a way to do this without overriding (and duplicating) the SendDocument function. Did I miss something obvious or is there no way to add custom headers depending on the mime content type? Thanks Lars -- 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 for DocumentToContentType
Oct 21, 2011 V7.41 Angus added OnHttpMimeContentType to allow
custom ContentTypes to be supported for unusual file extensions.
Very nice.
Is there a reason you placed the calls in this sequences? I think
procedure THttpConnection.SendDocument[..]
begin
ErrorSend := FALSE;
ProtoNumber:= 200;
TriggerMimeContentType(FDocument, FAnswerContentType); { V7.41 allow
content type to be changed }
if FAnswerContentType='' then // no callback or not handled? Let the
default function do it's magic.
FAnswerContentType := DocumentToContentType(FDocument);
[..]
is a little bit better (at least if you have a callback and a matching
MimeContentType). In the worst case you have one additional comparism
(FAnswerContentType='') in the best case the complete if..then..else
construct of the default function will be skipped. It also would enable the
user to replace the default function with a optimized search.
BTW: what is the local variable ErrorSend good for? I think it simply can
be kicked...
Another minor thing: Is there a special reason why the String parameters
(Filename) of the callbacks and the Trigger[..] procedures are not declared
as const? This also applies to the DocumentToContentType function.
Greetings
Lars
--
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] Small problem with ifdefs in httpSrv
Hi,
I found one small problem in the THttpConnection class:
FPostRcvBuf : array [0..1023] of Byte; { V7.30 }
FPostCounter : Int64; { V7.30 }
must to be placed before the
{$IFNDEF NO_AUTHENTICATION_SUPPORT}
block, otherwise you get compilation errors, if you use this directive.
Lars
--
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] Suggestion for DocumentToContentType
Hi, after getting chewed out (again!) for forgetting to extend the DocumentToContentType function after an update of ICS, I like to suggest an improvement. As base use a THashedStringlist (or something similar). Fill the list with the default extension/contentType names and values pairs and provide a public RegisterContentType procedure to add customized content types to the list. It might be actually faster (sorted list) than the old function... Maybe this is also the time to add use the registry to find MIME type for file types ;) Lars -- 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] HTTP Server creates extremly high CPU load
Thanks, I can confirm, it works now without problems.
Lars
-Original Message-
From: twsocket-boun...@elists.org
[mailto:twsocket-boun...@elists.org] On Behalf Of Arno Garrels
Sent: Friday, July 01, 2011 8:35 AM
To: ICS support mailing
Subject: Re: [twsocket] HTTP Server creates extremly high CPU load
Lars Gehre wrote:
I think, I found something.
Thanks for reporting, I just checked in a fix.
Available via SVN now or included in next daily snapshot
here: http://wiki.overbyte.be/wiki/index.php/ICS_Download
--
Arno Garrels
The problem seems to be the head request. Normaly you do a HEAD and
close the connection, but in my case it stays open and the
http server
gets stuck in an endless loop.
The culprits are:
procedure THttpConnection.SendDocument(SendType :
THttpSendType;const
CustomHeaders : String); and procedure
THttpConnection.ConnectionDataSent(Sender : TObject; Error :
WORD);
In SendDocument the fdocsize gets set to the size of the
stream and a
if SendType = httpSendHead then
FDocStream.Seek(0, soFromEnd)
And
if SendType = httpSendDoc then
SendStream
else
Send(nil, 0); { Added 15/04/02 } // this one
triggers the
ConnectionDataSent.
In ConnectionDataSent FDataSent = FDocSize is the end trigger but
ToSend := FDocSize - FDataSent; //fdatasent = 0
if ToSend FSndBlkSize then
ToSend := FSndBlkSize;
Count := FDocStream.Read(FDocBuf^, ToSend); // =0 because of
FDocStream.Seek(0, soFromEnd) in SendDocument
FDataSent := FDataSent + Count; { Count data which is sent
} // 0 + 0 = 0
if State = wsConnected then { Be sure to be still
connected... }
Send(FDocBuf, Count);{ before actually send any
data. } // starts it all over again...
Maybe a
if (FDataSent = FDocSize) or
(FDocStream.Position=FDocStream.Size) then begin
might be a solution, but I don't know enough of the inner
workings of
the http component to foresee possible side effects...
Lars
-Original Message-
From: twsocket-boun...@elists.org
[mailto:twsocket-boun...@elists.org] On Behalf Of Lars Gehre
Sent: Thursday, June 30, 2011 9:49 PM
To: 'ICS support mailing'
Subject: Re: [twsocket] HTTP Server creates extremly high CPU load
Well I was a little to fast with my conclusion. It only happens to
files in the demo because they have a proper header, the virtual
documents only give a 404 for a HEAD request.
The download is not of matter, the demo files are 500 bytes or so.
And the server load stays as long as the client is connected.
As I said, I was able to replicate this on two different
machines and
it is not limited to local access. cross tests between the
machines
also show this behaviour.
Lars
-Original Message-
From: twsocket-boun...@elists.org
[mailto:twsocket-boun...@elists.org] On Behalf Of Arno Garrels
Sent: Thursday, June 30, 2011 3:49 PM
To: ICS support mailing
Subject: Re: [twsocket] HTTP Server creates extremly high CPU load
Lars Gehre wrote:
I noticed one thing: This only happens if files are
involved, for
virtual documents it does not happen.
I cannot reproduce it, 0.0% CPU here.
I used the OverbyteIcsWebServ demo running on a Win7 quadcore.
However if I download a file with Firefox (100 Mbit/s LAN)
at around 6
MB/s CPU 0 uses ~25-30% and CPU 2 8-15%, overall usage of
the server
process ~8-10% reported by Process Explorer.
--
Arno Garrels
For the http server demo it means you need to open Index.html or
Form.html.
Lars
-Original Message-
From: twsocket-boun...@elists.org
[mailto:twsocket-boun...@elists.org] On Behalf Of Lars Gehre
Sent: Thursday, June 30, 2011 11:21 AM
To: 'ICS support mailing'
Subject: [twsocket] HTTP Server creates extremly high CPU load
Hello all,
I have a serious problem with the http server component from
ICS7 (downloaded from the repository last week).
I'm using the wininet api on the client side to open a (GET)
connection to a ICS http Server.
For certain reasons I need to query the HEAD in
intervals (while
the other get is still in progress).
As soon as I send the second request the CPU load of the http
server maxes out one CPU core.
Steps to reproduce:
- Run the http server demo from ics.
- Download the demo
www.dvbviewer.tv/icsproblem/icsproblem.zip source (delphi 7)
- Run the demo, enter the url of the demo server and press the
button.
- As soon as the call to GetFileSize is finished you
see the CPU
load of the webserver going up.
I checked it on two windows 7 (multicore) machines with
the same
result.
I also checked it against several other http servers
and none of
them had a problem with this kind
Re: [twsocket] HTTP Server creates extremly high CPU load
I noticed one thing: This only happens if files are involved, for virtual documents it does not happen. For the http server demo it means you need to open Index.html or Form.html. Lars -Original Message- From: twsocket-boun...@elists.org [mailto:twsocket-boun...@elists.org] On Behalf Of Lars Gehre Sent: Thursday, June 30, 2011 11:21 AM To: 'ICS support mailing' Subject: [twsocket] HTTP Server creates extremly high CPU load Hello all, I have a serious problem with the http server component from ICS7 (downloaded from the repository last week). I'm using the wininet api on the client side to open a (GET) connection to a ICS http Server. For certain reasons I need to query the HEAD in intervals (while the other get is still in progress). As soon as I send the second request the CPU load of the http server maxes out one CPU core. Steps to reproduce: - Run the http server demo from ics. - Download the demo www.dvbviewer.tv/icsproblem/icsproblem.zip source (delphi 7) - Run the demo, enter the url of the demo server and press the button. - As soon as the call to GetFileSize is finished you see the CPU load of the webserver going up. I checked it on two windows 7 (multicore) machines with the same result. I also checked it against several other http servers and none of them had a problem with this kind of usage. Thanks Lars -- 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] HTTP Server creates extremly high CPU load
Well I was a little to fast with my conclusion. It only happens to files in the demo because they have a proper header, the virtual documents only give a 404 for a HEAD request. The download is not of matter, the demo files are 500 bytes or so. And the server load stays as long as the client is connected. As I said, I was able to replicate this on two different machines and it is not limited to local access. cross tests between the machines also show this behaviour. Lars -Original Message- From: twsocket-boun...@elists.org [mailto:twsocket-boun...@elists.org] On Behalf Of Arno Garrels Sent: Thursday, June 30, 2011 3:49 PM To: ICS support mailing Subject: Re: [twsocket] HTTP Server creates extremly high CPU load Lars Gehre wrote: I noticed one thing: This only happens if files are involved, for virtual documents it does not happen. I cannot reproduce it, 0.0% CPU here. I used the OverbyteIcsWebServ demo running on a Win7 quadcore. However if I download a file with Firefox (100 Mbit/s LAN) at around 6 MB/s CPU 0 uses ~25-30% and CPU 2 8-15%, overall usage of the server process ~8-10% reported by Process Explorer. -- Arno Garrels For the http server demo it means you need to open Index.html or Form.html. Lars -Original Message- From: twsocket-boun...@elists.org [mailto:twsocket-boun...@elists.org] On Behalf Of Lars Gehre Sent: Thursday, June 30, 2011 11:21 AM To: 'ICS support mailing' Subject: [twsocket] HTTP Server creates extremly high CPU load Hello all, I have a serious problem with the http server component from ICS7 (downloaded from the repository last week). I'm using the wininet api on the client side to open a (GET) connection to a ICS http Server. For certain reasons I need to query the HEAD in intervals (while the other get is still in progress). As soon as I send the second request the CPU load of the http server maxes out one CPU core. Steps to reproduce: - Run the http server demo from ics. - Download the demo www.dvbviewer.tv/icsproblem/icsproblem.zip source (delphi 7) - Run the demo, enter the url of the demo server and press the button. - As soon as the call to GetFileSize is finished you see the CPU load of the webserver going up. I checked it on two windows 7 (multicore) machines with the same result. I also checked it against several other http servers and none of them had a problem with this kind of usage. Thanks Lars -- 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 -- 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] IGMP V3 proposal
I like to propose a code addition for IGMP V3
(http://de.wikipedia.org/wiki/Internet_Group_Management_Protocol) to the
OverbyteICSWSocket unit.
It is mostly used by professional equipment (Cisco Co) to join a multicast
group. We use it for our IPTV analyzing tool and the code is confirmed to
work. :)
Regards
Lars
Proposal:
Type
ip_mreq_source = record
imr_multiaddr: in_addr; // IP multicast address of group
imr_sourceaddr: in_addr; // IP address of source
imr_interface: in_addr; // local IP address of interface
end;
Const
IP_ADD_SOURCE_MEMBERSHIP = 15; // join IP group/source
{$EXTERNALSYM IP_ADD_SOURCE_MEMBERSHIP}
In the definition of
TCustomWSocket = class(TIcsWndControl)
[...]
FMultiCastAddrStr : String;
FMultiCastIpTTL : Integer;
FMultiCastSourceAddrStr: String; // the source IP of the multicast
[...]
property MultiCastAddrStr: String read FMultiCastAddrStr
write FMultiCastAddrStr;
property MultiCastIpTTL : Integer read FMultiCastIpTTL
write FMultiCastIpTTL;
property MultiCastSourceAddrStr: String read
FMultiCastSourceAddrStr
write
FMultiCastSourceAddrStr; // the source IP of the multicast property - must
be published in TWSocket
[...]
and in
procedure TCustomWSocket.Listen;
var
iStatus: Integer;
optval : Integer;
mreq : ip_mreq;
mreqSrc: ip_mreq_source; // new
[...]
SOCK_DGRAM :
begin
if FMultiCast then begin
if (FMultiCastSourceAddrStr='') then //simple join
begin
{ Use setsockopt() to join a multicast group }
{ mreq.imr_multiaddr.s_addr :=
WSocket_inet_addr('225.0.0.37');}
{ mreq.imr_multiaddr.s_addr := sin.sin_addr.s_addr;}
{ mreq.imr_multiaddr.s_addr :=
WSocket_inet_addr(FAddrStr);}
mreq.imr_multiaddr.s_addr :=
WSocket_Synchronized_inet_addr(AnsiString(FMultiCastAddrStr));
{ mreq.imr_interface.s_addr := htonl(INADDR_ANY);} { RK}
mreq.imr_interface.s_addr :=
WSocket_Synchronized_ResolveHost(AnsiString(FAddrStr)).s_addr;
iStatus := WSocket_Synchronized_SetSockOpt(FHSocket,
IPPROTO_IP,
IP_ADD_MEMBERSHIP,
mreq,
SizeOf(mreq));
if iStatus 0 then begin
SocketError('setsockopt(IP_ADD_MEMBERSHIP)');
Exit;
end;
end
else
begin //IGMP V3 Join
{ Use setsockopt() to join a multicast group }
mreqSrc.imr_multiaddr.s_addr :=
WSocket_Synchronized_inet_addr(AnsiString(FMultiCastAddrStr));
mreqSrc.imr_sourceaddr.s_addr :=
WSocket_Synchronized_inet_addr(AnsiString(FMultiCastSourceAddrStr));
mreqSrc.imr_interface.s_addr :=
WSocket_Synchronized_ResolveHost(AnsiString(FAddrStr)).s_addr;
iStatus := WSocket_Synchronized_SetSockOpt(FHSocket,
IPPROTO_IP,
IP_ADD_SOURCE_MEMBERSHIP,
@mreqSrc,
SizeOf(mreqSrc));
if iStatus 0 then begin
SocketError('setsockopt(IP_ADD_SOURCE_MEMBERSHIP)');
Exit;
end;
end;
end;
ChangeState(wsListening);
ChangeState(wsConnected);
TriggerSessionConnectedSpecial(0);
end;
--
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] Proposal for more contenttypes in DocumentToContentType in OverbyteIcsHttpSrv.pas
Hello! else if (Ext = 'doc') or (Ext = 'docx') then Result := 'application/msword' else if (Ext = 'xls') or (Ext = 'xlsx') then Result := 'application/vnd.ms-excel' else if (Ext = 'ppt') or (Ext = 'pptx') then Result := 'application/vnd.ms-powerpoint' In my opinion, such things shouldn't be kept in component's source code. There should be external (or stored as resource) configuration file that contains all extension-content type pairs. I agree, in fact, it should be a callback or a virtual helper method. I have situations where the content type is depended on the client (don't ask, UPnP does it to you) or depend on the application. It is not very nice to have to edit the ICS sources at all in this cases. Also in the THttpConnection.SendDocument would benefit from a callback (either to a client or a virtual method) to add some things to the header before it is send. Regards Lars -- 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] THttpServer fixes for ICS v5/6/7 uploaded to the SVNrepositories - please test!
Hi, Fixed responses and an infinite loop when a byte-range-set was unsatisfiable. Added a fix for content ranges with files 2GB as suggested by Lars Gehre l...@dvbviewer.com. Replaced symbol UseInt64ForHttpRange by STREAM64. -- Arno Garrels [TeamICS] Sorry for taking so long to give feedback. Tested your fixes and they work without problems in V5 and V6. Lars -- 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] HTTP Range Problems with Files 2 GB
Hello all, I'm currently working system for streaming (DVB-)Recordings via http/get with the ICS V5 http server and delphi 7. Most of these recordings are way bigger than 2 GB (MaxInt). The problem is easy to replicate: use VLC (videolan.org) to open a http-Stream on the http server demo and set the clientcnx.document to a TS/MPG recording bigger than 2GB, it simply won't play, smaller recordings play without problems. I believe all versions of ICS have these problems (at least with Delphi 7 but I don't think integer or longword are suddenly Int64 in newer delphi versions). The following routines have problems: - THttpRangeStream.AddPartStream(Value: TStream; AStartPos, AEndPos: Integer); Integer should be THttpRangeInt - THttpRangeStream.Read(var Buffer; Count: Longint): Integer; Result := FSize - FPosition; // don't - Overflow, use seperate Variable - THttpRangeInt ActSize := min(Count - DataRead, Rec.Size - (ActOffset)); //Overflow because min only handles Integer. - THttpConnection.ConnectionDataSent(Sender : TObject; Error : WORD); var Count : Integer; ToSend : Integer; // Overflow in both use THttpRangeInt instead. - procedure ParseRangeString(var FromStr : String; var ToStr : String; const Value : String); Don't use StrToInt, Use StrToInt64 - THttpRangeList.InitFromString(AStr: String); Don't use StrToInt, Use StrToInt64 After these corrections, ICS works flawless, even jumping around in a 16 GB HDTV Recording works without glitches. I simply love ICS! ;) Greetings Lars -- 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] HTTP Range Problems with Files 2 GB
Lars Gehre wrote:
I believe all versions of ICS have these problems (at least with
Delphi 7 but I don't think integer or longword are suddenly
Int64 in
newer delphi versions).
It seems that ICSv6 and v7 both support Int64:
{$IFDEF UseInt64ForHttpRange}
THttpRangeInt= Int64;
{$ELSE}
THttpRangeInt= LongInt; { Limited to 2GB size }
{$ENDIF}
If you use Delphi 7 you upgrade to ICSv6 or even ICSv7.
V5 does support it also. That's why I wrote THttpRangeInt. :)
The problems still exists because integer and THttpRangeInt are constantly
mixed, as I wrote. At least in V7 Code the same routines are used and will
also cause the described problems.
I tried V6, but it does not work very well with continous streams, so I will
stick with V5, which has proven over the last three years to be extremly
stable in streaming.
Lars
--
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
The following routines have problems:
- THttpRangeStream.AddPartStream(Value: TStream; AStartPos, AEndPos:
Integer);
Integer should be THttpRangeInt
- THttpRangeStream.Read(var Buffer; Count: Longint):
Integer; Result
:= FSize - FPosition; // don't - Overflow, use seperate
Variable -
THttpRangeInt
ActSize := min(Count - DataRead, Rec.Size - (ActOffset));
//Overflow
because min only handles Integer.
- THttpConnection.ConnectionDataSent(Sender : TObject;
Error : WORD);
var
Count : Integer;
ToSend : Integer; // Overflow in both use THttpRangeInt instead.
- procedure ParseRangeString(var FromStr : String; var ToStr :
String; const Value : String);
Don't use StrToInt, Use StrToInt64
- THttpRangeList.InitFromString(AStr: String); Don't use StrToInt,
Use StrToInt64
After these corrections, ICS works flawless, even jumping
around in a
16 GB HDTV Recording works without glitches. I simply love ICS! ;)
Greetings
Lars
--
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
