As Piotr explained, there is no need for threads--it could all be async! In
the THttpConnectıonö we need a dynamıc array of requests and when they are
storedö we answer them one by one.
Regards,
SZ
- Original Message -
From: "Francois PIETTE" <[EMAIL PROTECTED]>
To: "ICS support maili
Hello!
>> If you look at the rfc, the requests are meant to be executed serially.
> The responses must be provided in the same sequence as the requests. This
> doesn't mean that each request can't be executed by a separate thread. As I
> said, responses has to be serialized to be sent in the co
Inside a THttpServer.OnGetDocument event, I have been using several THttpCli
objects sucessfully for quite a while using Get. As my data returned is
growing every month, i would like to start using GetAsync.
The problem i have is, my data is returned in THttpCli.OnDocDone & i am
unable to access TH
Hello!
>> I wonder the optional RFC2616 pipelining mechanism for requests in
>> HTTP/1.1
>> is anything utilized by clients in the real world or just hypothetical?
>> Currently no ICS code (client/server) supports it.
> Pipelining use would require changing the state machine in ICS component. At
> How can different threads respond to the same socket??
> Seems impossible to me.
As I said:
>> Pipelining use would require changing the state machine in ICS component.
The change is to clearly separate the execution of the request from the
state machine so that it can be delegated to a thread
- Original Message -
From: "Francois PIETTE" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Saturday, July 29, 2006 6:17 PM
Subject: Re: [twsocket] HTTP/1.1 pipelining--any need?
>> I wonder the optional RFC2616 pipelining mechanism for requests in
>> HTTP/1.1
>> is anything utiliz
> I wonder the optional RFC2616 pipelining mechanism for requests in
> HTTP/1.1
> is anything utilized by clients in the real world or just hypothetical?
> Currently no ICS code (client/server) supports it.
Pipelining use would require changing the state machine in ICS component. At
first glance
>>> assign the sAcceptSocket to property TWSocket.Handle?
>>
>> That's what Dup() is all about. Dup() assign a socket handle to an
>> existing TWSocket instance.
>
> Sure, but I was asking because of this note in the docs:
> When this operation is successfully completed, sAcceptSocket can be
> pas
Francois PIETTE wrote:
>> assign the sAcceptSocket to property TWSocket.Handle?
>
> That's what Dup() is all about. Dup() assign a socket handle to an
> existing TWSocket instance.
Sure, but I was asking because of this note in the docs:
When this operation is successfully completed, sAcceptSocke
> assign the sAcceptSocket to property TWSocket.Handle?
That's what Dup() is all about. Dup() assign a socket handle to an existing
TWSocket instance.
> can I achieve that calling TWSocket.Close wont close the
> socket handle so it can be reused?
This would require a change in the component to
Hello,
I wonder the optional RFC2616 pipelining mechanism for requests in HTTP/1.1
is anything utilized by clients in the real world or just hypothetical?
Currently no ICS code (client/server) supports it.
Best Regards,
SubZero
--
To unsubscribe or change your settings for TWSocket mailing
Arno Garrels wrote:
> Hello,
>
> Today I found AcceptEx() in winsock API
> (http://msdn.microsoft.com/library/en-
> us/winsock/winsock/acceptex_2.asp?frame=true) and I wonder whether
> the function might be usefull in a multi-threaded TWSocketServer. It
> is capable to accept into an already exist
Hello,
I have read the description and believe that this could be useful with
socket-pooling (like thread pooling). As you said, for this technique, we
need the shutdown/close not to destroy the twsocket. It seems the paradigm
changes a bit but in the code level I doubt it would require too muc
Hello,
Today I found AcceptEx() in winsock API
(http://msdn.microsoft.com/library/en-us/winsock/winsock/acceptex_2.asp?frame=true)
and I wonder whether the function might be usefull in a
multi-threaded TWSocketServer. It is capable to accept into an
already existing socket which promises to be
Hello Wilfred,
But how I can detect that SmtpCli->Abort() is finished, component is
ready and I can call SmtpCli->Connect again for next message ?
If I call SmtpCli->Connect() IMMEDIATELY after SmtpCli->Abort()
I should receive "Component Not Ready" error, right ?
If SmtpCli->Abort() is called o
Hello Max,
Use OnRequestDone to trigger next sending, not OnStateChange or
OnSessionClosed. Both latter are more for log or display updates.
---
Rgds, Wilfried [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
http://www.mestdagh.biz
Saturday, July 29, 2006, 11:48, Max Terentiev wrote:
Helo,
What is a best event for starting new Smtp session (e.g.
start sending next message after previous is sent or aborted)?
I was try to Use OnSessionClosed or OnStateChange events
(in OnStateChange i wait for SmtpCli->State==smtpReady and
Smtp->CtrlSocket->State=wsClosed).
But anyway i receiv
As I understand, you where - before you fix - sending some data which will
result is some response being received, but at the time you send data your
code is not yet ready to process the response. When runnin on different
computers, there was enough time between the time you send the data and th
> My program uses TSmtpCli and I receive this exception time to time:
>
> "Error in function WSACancelAsyncRequest - Invalid Argument."
>
> How to avoid this error ?
This is very strange. This error should never occur unless there is a bug
somewhere in your program in a part probably not related t
19 matches
Mail list logo
