Hi everyone,
Will creating a socket in one thread and destroying it in another cause any
problems ?
Regards,
Daniel
--
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.b
Hi,
I think that If you protect what you do with semaphores it is possible but its
better to handle it all under one thread.
BR,
Noam.
From: TWSocket on behalf of Daniel Mauric
Sent: Thursday, May 12, 2016 11:12 AM
To: twsocket@lists.elists.org
Subj
> I still have some Windows 7 VMs, so will do more testing next
> week, once the new OpenSSL stuff is finished.
Not done any changes or real testing yet, except to confirm that HTTPS
downloads are currently the same speed as HTTP, although one would
expect the encryption overhead to slow things
Note that the original subject is a bit misleading, the issue is not about
ssl POST, but POST in general, whether on http or https.
On Thu, May 12, 2016 at 12:13 PM, Angus Robertson - Magenta Systems Ltd <
an...@magsys.co.uk> wrote:
> > I still have some Windows 7 VMs, so will do more testing nex
> Note that the original subject is a bit misleading, the issue is
> not about ssl POST, but POST in general, whether on http or https.
And my comments were mostly related to GET/POST in general, not
specifically SSL which one might expect to slow things down, but not
necessarily.
Angus
--
To
GET seems fine though. You mentioned changing the buffer size, where would
you do that? I tried changing 8k to 64k in OverbyteIcsHttpProt.pas here,
but it made no difference:
~4617
procedure THttpCli.SocketDataSent(Sender : TObject; ErrCode : Word);
var
Len : Integer;
begin
if not FAllowed
> GET seems fine though. You mentioned changing the buffer size,
> where would you do that?
I've not yet looked closely at the code, once SSL is done.
> I tried changing 8k to 64k in OverbyteIcsHttpProt.pas here,
> but it made no difference:
But then you discovered the low speeds only happene
Erm, I thought we all reached a clear conclusion that the issue happens
from w98 to w7, and whatever causes the problem seems fixed from w8
onwards. Since all the tests were compared with a different tcp/ip library
at the exact same time of performing the ICS tests, I think we can rule out
random t
Checked again just now, w7:
ICS with 64k buffer: Upload Duration: 33.2 secs / Speed: 137,151 chars/sec
SYN: Upload Duration: 2 secs / Speed: 2,275,855 chars/sec
On Thu, May 12, 2016 at 4:04 PM, brian - wrote:
> Erm, I thought we all reached a clear conclusion that the issue happens
> from w98 t
The ICS code doesn't change when running in W8 or W10, so the issue is
probably related to how the async routines are handled by the sockets
API (or how messages are delivered, synchronization handled, etc) in the
different Windows.
If that's the case, using SYN, that is sync, to compare against
On Thu, May 12, 2016 at 4:24 PM, RTT wrote:
>
> If that's the case, using SYN, that is sync, to compare against the async
> ICS is not of any help. You need to compare with another async component.
I think all other libraries are blocking, Indy, Synapse, Delphi's own
tcp/ip stuff. Either way,
Either way, if the problem is the async nature of ICS,
shouldn't an alternate method be provided?
Try with the TransmitFile function
https://msdn.microsoft.com/en-us/library/windows/desktop/ms740565(v=vs.85).aspx
You may create a descendant of the THttpCli, override the SocketDataSent
metho
12 matches
Mail list logo
