Re: [twsocket] OverbyteIcsHttpSrv V7
Sadly you removed the possibility to completely exclude linkage to ICS ZLib :( This is consistent behaviour with other ICS v7 components, content compression is determined by configuration defaulting as disabled, not by compiler defines. There is nothing to stop you using alternative compression libraries, I have applications using different components each with their own versions of zlib. The workaround to use the ZLibDll could work, but this unit is loading the DLL at initialization I don't believe anyone ever used the DLL, once the linked OBJ files became stable. It's a feature more likely to be removed, than changed so every unit using zlib breaks. 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] connection limit?
Hello Flavio, Not a known issue. But when it accept new connections after you restart your application, maybe you are out of nonpaged memory? (sockets use nonpaged). --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Monday, June 15, 2009, 22:08, Flavio Goncalves wrote: I have an application dealing with GPRS connections, and there is a lot of connections/disconnections going all the time. The remote client connect to the server then send the authentication data. Sometimes there are bad connections and the remote client connects but the data never reach the server, and soon a timeout occurs and a new connection attempt is made. The server side have a timeout for incoming connections without authentication, and when it triggers a peer.close is called server side. After some time (4 or 5 days) the GPRS socket just stop accepting connections, but other sockets (on other ports) continue working. I did a function freeing the component and creating a new one with no success, that port dont accept new connections yet. Finally I close and then reopen the application, and everything is working again. Anyone have seen this before? Im using Delphi 7, and this app runs on Windows XP Professional. I wasnt using the latest ICS so im asking hoping this can be a know issue someone can answer now, but I already download the V5 one and will install it now. Thanks Flavio -- 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] OverbyteIcsHttpSrv V7
There is nothing to stop you using alternative compression libraries, I have applications using different components each with their own versions of zlib. Yes, of course, but why increase final application size, and resources used, if we can simple add the possibility to not duplicate it, if not needed? If we are not going to use compression, or we are handling it in our own code, why link the zlib library? The workaround to use the ZLibDll could work, but this unit is loading the DLL at initialization I don't believe anyone ever used the DLL, once the linked OBJ files became stable. It's a feature more likely to be removed, than changed so every unit using zlib breaks. I don't want to use the DLL version either, I'm running my own encoding code by handling it thru the OnContentEncode event, so that internal compression code is never called, but setting it to use the ZLIB DLL version means the ZLIB obj's are not linked. Just a workaround to achieve my desire to not duplicate resources. And, remember, at current version, you are offering the possibility to use the DLL version, so the proposed fix to load the DLL just when needed, and check for correct load before calling its functions, is really a need. And the other suggestion to always call the OnContentEncode, if assigned and hoContentEncoding in server options, despite the internal content type and stream size checks? -- 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] OverbyteIcsHttpSrv V7
If we are not going to use compression, or we are handling it in our own code, why link the zlib library? You said you are not using the v7 component, so none of this currently effects your applications. It is not realistic to make the code more complicated just to satisfy compatibility for one user that may or may not use it sometime in the future. Now that content encoding is available for all component users, your own code could be abandoned so it's a non-issue. The size increase adding the zlib code is not that much, about 21K, particularly compared to the vast Delphi visual runtime library that brings in hundreds of kilobytes of components that are rarely used, like action lists, image lists, docking, etc. And the other suggestion to always call the OnContentEncode, if assigned and hoContentEncoding in server options, despite the internal content type and stream size checks? That would mean the user had to repeat the content type and size tests in the event, before deciding whether to look-up a cached compressed file. But I accept the tests need to be improved, I forgot about compressing XML content for instance. So I will move the tests into a virtual function that can be overridden in an application to give total control (and save some duplicated code). 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
[twsocket] TEmulVT problem..
Using TEmulVT , which has worked out really well, i ran into an issue where if i send it a string that is more then 80chars wide, it won't wrap down to the next line? if i send a string of 100 chars, it will display a whole line of them even tho the column setting is 80. On the other side of the connection (telnet) they will wrap down. am i missing something? -Steven -- 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] TEmulVT problem..
Using TEmulVT , which has worked out really well, i ran into an issue where if i send it a string that is more then 80chars wide, it won't wrap down to the next line? if i send a string of 100 chars, it will display a whole line of them even tho the column setting is 80. On the other side of the connection (telnet) they will wrap down. am i missing something? I have checked right now using TcpSrv demo program and TnClient demo program. Characters are displayed on next line when 80 characters are reached. (You may need to edit TcpSrv LineLimit to accept lines longer than 80 characters). Maybe the effect you see depend on your system. You have not described how you use TEmulVT so I can't help much. -- 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] OverbyteIcsHttpSrv V7
If we are not going to use compression, or we are handling it in
our own code, why link the zlib library?
You said you are not using the v7 component, so none of this currently
effects your applications. It is not realistic to make the code more
complicated just to satisfy compatibility for one user that may or may
not use it sometime in the future.
Changing this
if (ZStreamType zsZLib) then begin
to this
if (ZStreamType zsZLib) {$IFNDEF USE_ZLIB_OBJ}and ZLibLoaded {$ENDIF}
then begin
and adding that ZLibLoaded function, needed to at same time make your
code bug free if user decide to use ZLIBDLL, is turning the code much
more complicated?!!!
The size increase adding the zlib code is not that much, about 21K,
particularly compared to the vast Delphi visual runtime library that
brings in hundreds of kilobytes of components that are rarely used, like
action lists, image lists, docking, etc.
Agree, but I know it's there, and just a little code change can remove
these extra bytes, change that don't impact anyhow with component
functionality.
VCL bad implementation in the use of resources, and size occupied by not
used code that result mostly because of the not so smart linker, are not
good examples.
And the other suggestion to always call the OnContentEncode, if
assigned and hoContentEncoding in server options, despite the
internal content type and stream size checks?
That would mean the user had to repeat the content type and size tests in
the event, before deciding whether to look-up a cached compressed file.
Content-Encoding is not just compression. It's an elegant way to use
custom, not standard, encodings in custom server-client applications.
Your internal imposed rule to call the OnContentEncode only after
internal check of imposed rules is not optimal and completely obliterate
the idea of that event.
And you can always add a new variable to that event that can be used to
force compression, bypassing that internal check.
ForceCompression:=false;
ContentEncodingHandled:=false;
TriggerContentEncode(ContentEncoding, ContentEncodingHandled,
ForceCompression);
if ContentEncodingHandled then
PutStringInSendBuffer('Content-Encoding: ' + ContentEncoding +
#13#10)
else
if ForceCompression or
(((ContType = '') or (Pos ('text/', ContType) 0)) and {
only compress textual stuff }
((FDocStream.Size = FServer.SizeCompressMin) and {
too small a waste of time }
(FDocStream.Size FServer.SizeCompressMax))) then begin { too
large will block server and use a lot of memory }
...
But I accept the tests need to be improved, I forgot about compressing
XML content for instance. So I will move the tests into a virtual
function that can be overridden in an application to give total control
(and save some duplicated code).
Yes, all current content-encoding code is duplicated in AnswerStream and
SendDocument, so perfectly viable for a procedure.
For the valid to compress content-type check, it is probably more
functional the use of a published string property, where to concatenate
all the valid content type distinct strings that can be checked by a
simple string search against the stream content type.
Rui
--
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
