Hello Hoby,
If PutDataInSendBuffer and Send 0 at the end makes a difference then you
probably have a problem in the receiver. Same reason as the reason it
depent from machine to machine. You can try also with SocketSpy, if it
also make a difference then you sure have to check over there.
- You
Hello Max,
If winsock complains about an Invalid argument, than you have probably
some pointer overritten or othere memory problem in your application.
There is a debugger setting for overwriting memory, but never tryed it
or know that it works well.
---
Rgds, Wilfried [TeamICS]
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 to
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
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 receive
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:
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 only
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,
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
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 existing
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
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
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, sAcceptSocket
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
passed, but to
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 I
- Original Message -
From: Francois PIETTE [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
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
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.
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
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
19 matches
Mail list logo
