dear all,

 i'm working on developing an extension for the purpose of some long-timed 
requests, so after writing the main blocks of the code using VC++6.0 + MFC 
that includes a separate thread pool & some shared datastructures with simple 
sync mechanism, my test is as follows:

1- return HSE_STATUS_PENDING to the server

2- pass pCtxt to my thread pool

3- threadpool will check periodically for active connections, and when a 
connection reaches a certain time (eg: 30 sec- 2 min) it uses writeclient() 
for sending reply then it call ServerSupportFunction() with 
HSE_REQ_DONE_WITH_SESSION and removes pCtxt from my active conn.(s)' list

4- the client that i used for testing do open multiple connections 
requesting ext.'s dll from the server, so i can detect number of simaltenious 
conn.(s)

but i found something strange, the client can only have 2 simalt. conn.(s) 
active with iis at a time, and any new request come from the same ip, the iis 
reuse one of the 2 active conn.(s)' connID to be used with it, even i think 
it leaves all the sockets opening (old and new) but reuse connID which is 
used by writeclient(), so in my test, the last 2 conn.(s) recieved all the 
sent data to the opened connections.

if this is a limitation of win xp iis, so how could this operate if the 
requests are coming from behind nat or proxy.

another question is about async callbacks, if i used async writeclient() for 
example, can i access any shared data inside dll from it or i can use only 
pECB's included functions pointers (as callback is not running actually in my 
dll ??), seems no to me (accessing shared data failed) !!!, and how could i 
use the pContext arg of callback, should i pass the pCtxt first when i call 
ServerSupportFunction() with HSE_REQ_IO_COMPLETION as the last parameter.

 thx,

with regards

On Jan 13, 3:07 pm, Ibrahim Shahin
 wrote:
> dear all,
>
>  i'm working on developing an extension for the purpose of some long-timed
> requests, so after writing the main blocks of the code using VC.0  MFC> that includes a separate thread pool & some shared datastructures with simple
> sync mechanism, my test is as follows:
>
> 1- return HSE_STATUS_PENDING to the server
>
> 2- pass pCtxt to my thread pool
>
> 3- threadpool will check periodically for active connections, and when a
> connection reaches a certain time (eg: 30 sec- 2 min) it uses writeclient(> for sending reply then it call ServerSupportFunction() with
> HSE_REQ_DONE_WITH_SESSION and removes pCtxt from my active conn.(s)' list
>
> 4- the client that i used for testing do open multiple connections
> requesting ext.'s dll from the server, so i can detect number of simaltenious
> conn.(s)
>
> but i found something strange, the client can only have 2 simalt. conn.(s)> active with iis at a time, and any new request come from the same ip, the iis
> reuse one of the 2 active conn.(s)' connID to be used with it, even i think
> it leaves all the sockets opening (old and new) but reuse connID which is
> used by writeclient(), so in my test, the last 2 conn.(s) recieved all the> sent data to the opened connections.
>
> if this is a limitation of win xp iis, so how could this operate if the
> requests are coming from behind nat or proxy.
>
> another question is about async callbacks, if i used async writeclient() for
> example, can i access any shared data inside dll from it or i can use only> pECB's included functions pointers (as callback is not running actually in my
> dll ??), seems no to me (accessing shared data failed) !!!, and how could i
> use the pContext arg of callback, should i pass the pCtxt first when i call
> ServerSupportFunction() with HSE_REQ_IO_COMPLETION as the last parameter.
>
>  thx,
>
> with regards


That two connection limit seems to come from your test client -- for
example, WinInet (what IE uses) has such a limit against a single
server.

However, IIS 5.1 on XP Pro does have a 10 connection limit, so it will
not be ideal for you to test your particular behavior even when you
unblock the test client.

The way you describe your testing of long async requests is strange.
All you need is a thread pool whose threadproc sleeps 30 sec to 2
minutes before using the ECB to WriteClient and DoneWithSession. There
is no need for threadpool to check for active connections. Makes me
wonder if you have a correctly written Threadpool.

Please show the code illustrating what you are talking about (put in
comments where you are having questions/problems). I cannot understand
how exactly you are trying to "share data" and when you are trying to
"use pContext". What you want to do is possible -- it is a matter of
the right sequence of code, but I can't tell what your current
sequence is.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

thx for your reply,

1st, i'm not using a normal http client (browser) like IE, i knew that HTTP 
1.1 standards force the 2 connections limitation for a certain server and 
also knew the iis's 10 conn.(s) limit, but i do coded a simple client using 
winsocks that do multiple requests to the iis server using http protocol, so 
why did iis reuse the connID ?.

2nd, about my thread-pool design, the delay will not accur inside my dll's 
threads but it'll carried out in another process, so all what i need is 
checking for the finished tasks and send response back to the client using 
writeclient().

3rd, about the async operations, if i will allocate some sort of data inside 
my dll (not through iis) per each request, so how could i pass a pointer for 
it to the callback function ?.

i hope that the scenario is more clear now, and if u need an explanation for 
anything after that i can add some blocks of code later.

"David Wang" wrote:

> On Jan 13, 3:07 pm, Ibrahim Shahin
>  wrote:
> > dear all,
> >
> >  i'm working on developing an extension for the purpose of some long-timed
> > requests, so after writing the main blocks of the code using VC++6.0 + MFC
> > that includes a separate thread pool & some shared datastructures with simple
> > sync mechanism, my test is as follows:
> >
> > 1- return HSE_STATUS_PENDING to the server
> >
> > 2- pass pCtxt to my thread pool
> >
> > 3- threadpool will check periodically for active connections, and when a
> > connection reaches a certain time (eg: 30 sec- 2 min) it uses writeclient()
> > for sending reply then it call ServerSupportFunction() with
> > HSE_REQ_DONE_WITH_SESSION and removes pCtxt from my active conn.(s)' list
> >
> > 4- the client that i used for testing do open multiple connections
> > requesting ext.'s dll from the server, so i can detect number of simaltenious
> > conn.(s)
> >
> > but i found something strange, the client can only have 2 simalt. conn.(s)
> > active with iis at a time, and any new request come from the same ip, the iis
> > reuse one of the 2 active conn.(s)' connID to be used with it, even i think
> > it leaves all the sockets opening (old and new) but reuse connID which is
> > used by writeclient(), so in my test, the last 2 conn.(s) recieved all the
> > sent data to the opened connections.
> >
> > if this is a limitation of win xp iis, so how could this operate if the
> > requests are coming from behind nat or proxy.
> >
> > another question is about async callbacks, if i used async writeclient() for
> > example, can i access any shared data inside dll from it or i can use only
> > pECB's included functions pointers (as callback is not running actually in my
> > dll ??), seems no to me (accessing shared data failed) !!!, and how could i
> > use the pContext arg of callback, should i pass the pCtxt first when i call
> > ServerSupportFunction() with HSE_REQ_IO_COMPLETION as the last parameter.
> >
> >  thx,
> >
> > with regards
> 
> 
> That two connection limit seems to come from your test client -- for
> example, WinInet (what IE uses) has such a limit against a single
> server.
> 
> However, IIS 5.1 on XP Pro does have a 10 connection limit, so it will
> not be ideal for you to test your particular behavior even when you
> unblock the test client.
> 
> The way you describe your testing of long async requests is strange.
> All you need is a thread pool whose threadproc sleeps 30 sec to 2
> minutes before using the ECB to WriteClient and DoneWithSession. There
> is no need for threadpool to check for active connections. Makes me
> wonder if you have a correctly written Threadpool.
> 
> Please show the code illustrating what you are talking about (put in
> comments where you are having questions/problems). I cannot understand
> how exactly you are trying to "share data" and when you are trying to
> "use pContext". What you want to do is possible -- it is a matter of
> the right sequence of code, but I can't tell what your current
> sequence is.
> 
> 
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>

AFAIK connID is just a pointer to a block of memory, and IIS re-uses 
these in order to improve performance. So even if its a connID you've 
seen before, it doesn't mean its the same physical socket connection.

It sounds like you are using some kind of polling for the thread pool, 
which generally you should avoid. Use one of the WaitFor* APIs,  e.g. 
WaitForSingleObject, to wait for completion of an external task, e.g. 
another process.

Ian

Ibrahim Shahin wrote:
> thx for your reply,
> 
> 1st, i'm not using a normal http client (browser) like IE, i knew that HTTP 
> 1.1 standards force the 2 connections limitation for a certain server and 
> also knew the iis's 10 conn.(s) limit, but i do coded a simple client using 
> winsocks that do multiple requests to the iis server using http protocol, so 
> why did iis reuse the connID ?.
> 
> 2nd, about my thread-pool design, the delay will not accur inside my dll's 
> threads but it'll carried out in another process, so all what i need is 
> checking for the finished tasks and send response back to the client using 
> writeclient().
> 
> 3rd, about the async operations, if i will allocate some sort of data inside 
> my dll (not through iis) per each request, so how could i pass a pointer for 
> it to the callback function ?.
> 
> i hope that the scenario is more clear now, and if u need an explanation for 
> anything after that i can add some blocks of code later.
> 
> "David Wang" wrote:
> 
>> On Jan 13, 3:07 pm, Ibrahim Shahin
>>  wrote:
>>> dear all,
>>>
>>>  i'm working on developing an extension for the purpose of some long-timed
>>> requests, so after writing the main blocks of the code using VC++6.0 + MFC
>>> that includes a separate thread pool & some shared datastructures with simple
>>> sync mechanism, my test is as follows:
>>>
>>> 1- return HSE_STATUS_PENDING to the server
>>>
>>> 2- pass pCtxt to my thread pool
>>>
>>> 3- threadpool will check periodically for active connections, and when a
>>> connection reaches a certain time (eg: 30 sec- 2 min) it uses writeclient()
>>> for sending reply then it call ServerSupportFunction() with
>>> HSE_REQ_DONE_WITH_SESSION and removes pCtxt from my active conn.(s)' list
>>>
>>> 4- the client that i used for testing do open multiple connections
>>> requesting ext.'s dll from the server, so i can detect number of simaltenious
>>> conn.(s)
>>>
>>> but i found something strange, the client can only have 2 simalt. conn.(s)
>>> active with iis at a time, and any new request come from the same ip, the iis
>>> reuse one of the 2 active conn.(s)' connID to be used with it, even i think
>>> it leaves all the sockets opening (old and new) but reuse connID which is
>>> used by writeclient(), so in my test, the last 2 conn.(s) recieved all the
>>> sent data to the opened connections.
>>>
>>> if this is a limitation of win xp iis, so how could this operate if the
>>> requests are coming from behind nat or proxy.
>>>
>>> another question is about async callbacks, if i used async writeclient() for
>>> example, can i access any shared data inside dll from it or i can use only
>>> pECB's included functions pointers (as callback is not running actually in my
>>> dll ??), seems no to me (accessing shared data failed) !!!, and how could i
>>> use the pContext arg of callback, should i pass the pCtxt first when i call
>>> ServerSupportFunction() with HSE_REQ_IO_COMPLETION as the last parameter.
>>>
>>>  thx,
>>>
>>> with regards
>>
>> That two connection limit seems to come from your test client -- for
>> example, WinInet (what IE uses) has such a limit against a single
>> server.
>>
>> However, IIS 5.1 on XP Pro does have a 10 connection limit, so it will
>> not be ideal for you to test your particular behavior even when you
>> unblock the test client.
>>
>> The way you describe your testing of long async requests is strange.
>> All you need is a thread pool whose threadproc sleeps 30 sec to 2
>> minutes before using the ECB to WriteClient and DoneWithSession. There
>> is no need for threadpool to check for active connections. Makes me
>> wonder if you have a correctly written Threadpool.
>>
>> Please show the code illustrating what you are talking about (put in
>> comments where you are having questions/problems). I cannot understand
>> how exactly you are trying to "share data" and when you are trying to
>> "use pContext". What you want to do is possible -- it is a matter of
>> the right sequence of code, but I can't tell what your current
>> sequence is.
>>
>>
>> //David
>> http://w3-4u.blogspot.com
>> http://blogs.msdn.com/David.Wang
>> //
>>

thx, how could iis reuse it while the other connection is still active ??, 
then how iis will differ between active requests which have the same connID ??

"Ian" wrote:

> AFAIK connID is just a pointer to a block of memory, and IIS re-uses 
> these in order to improve performance. So even if its a connID you've 
> seen before, it doesn't mean its the same physical socket connection.
> 
> It sounds like you are using some kind of polling for the thread pool, 
> which generally you should avoid. Use one of the WaitFor* APIs,  e.g. 
> WaitForSingleObject, to wait for completion of an external task, e.g. 
> another process.
> 
> Ian
> 
> Ibrahim Shahin wrote:
> > thx for your reply,
> > 
> > 1st, i'm not using a normal http client (browser) like IE, i knew that HTTP 
> > 1.1 standards force the 2 connections limitation for a certain server and 
> > also knew the iis's 10 conn.(s) limit, but i do coded a simple client using 
> > winsocks that do multiple requests to the iis server using http protocol, so 
> > why did iis reuse the connID ?.
> > 
> > 2nd, about my thread-pool design, the delay will not accur inside my dll's 
> > threads but it'll carried out in another process, so all what i need is 
> > checking for the finished tasks and send response back to the client using 
> > writeclient().
> > 
> > 3rd, about the async operations, if i will allocate some sort of data inside 
> > my dll (not through iis) per each request, so how could i pass a pointer for 
> > it to the callback function ?.
> > 
> > i hope that the scenario is more clear now, and if u need an explanation for 
> > anything after that i can add some blocks of code later.
> > 
> > "David Wang" wrote:
> > 
> >> On Jan 13, 3:07 pm, Ibrahim Shahin
> >>  wrote:
> >>> dear all,
> >>>
> >>>  i'm working on developing an extension for the purpose of some long-timed
> >>> requests, so after writing the main blocks of the code using VC++6.0 + MFC
> >>> that includes a separate thread pool & some shared datastructures with simple
> >>> sync mechanism, my test is as follows:
> >>>
> >>> 1- return HSE_STATUS_PENDING to the server
> >>>
> >>> 2- pass pCtxt to my thread pool
> >>>
> >>> 3- threadpool will check periodically for active connections, and when a
> >>> connection reaches a certain time (eg: 30 sec- 2 min) it uses writeclient()
> >>> for sending reply then it call ServerSupportFunction() with
> >>> HSE_REQ_DONE_WITH_SESSION and removes pCtxt from my active conn.(s)' list
> >>>
> >>> 4- the client that i used for testing do open multiple connections
> >>> requesting ext.'s dll from the server, so i can detect number of simaltenious
> >>> conn.(s)
> >>>
> >>> but i found something strange, the client can only have 2 simalt. conn.(s)
> >>> active with iis at a time, and any new request come from the same ip, the iis
> >>> reuse one of the 2 active conn.(s)' connID to be used with it, even i think
> >>> it leaves all the sockets opening (old and new) but reuse connID which is
> >>> used by writeclient(), so in my test, the last 2 conn.(s) recieved all the
> >>> sent data to the opened connections.
> >>>
> >>> if this is a limitation of win xp iis, so how could this operate if the
> >>> requests are coming from behind nat or proxy.
> >>>
> >>> another question is about async callbacks, if i used async writeclient() for
> >>> example, can i access any shared data inside dll from it or i can use only
> >>> pECB's included functions pointers (as callback is not running actually in my
> >>> dll ??), seems no to me (accessing shared data failed) !!!, and how could i
> >>> use the pContext arg of callback, should i pass the pCtxt first when i call
> >>> ServerSupportFunction() with HSE_REQ_IO_COMPLETION as the last parameter.
> >>>
> >>>  thx,
> >>>
> >>> with regards
> >>
> >> That two connection limit seems to come from your test client -- for
> >> example, WinInet (what IE uses) has such a limit against a single
> >> server.
> >>
> >> However, IIS 5.1 on XP Pro does have a 10 connection limit, so it will
> >> not be ideal for you to test your particular behavior even when you
> >> unblock the test client.
> >>
> >> The way you describe your testing of long async requests is strange.
> >> All you need is a thread pool whose threadproc sleeps 30 sec to 2
> >> minutes before using the ECB to WriteClient and DoneWithSession. There
> >> is no need for threadpool to check for active connections. Makes me
> >> wonder if you have a correctly written Threadpool.
> >>
> >> Please show the code illustrating what you are talking about (put in
> >> comments where you are having questions/problems). I cannot understand
> >> how exactly you are trying to "share data" and when you are trying to
> >> "use pContext". What you want to do is possible -- it is a matter of
> >> the right sequence of code, but I can't tell what your current
> >> sequence is.
> >>
> >>
> >> //David
> >> http://w3-4u.blogspot.com
> >> http://blogs.msdn.com/David.Wang
> >> //
> >>
>

1. You should consider the ConnID value as opaque. If you do your part
correctly, IIS will do its part correctly. As for why ConnID is re-
used -- IIS is an optimized server that uses allocation caching to
avoiding hitting the heap -- and ConnID comes out of that cache --
thus if your code acts correctly, IIS will give you the right values.

2. That sounds like a "polling" approach to introduce delay, which you
should avoid. Like I said, it is really easy to simulate a "long
running asynchronous operation" -- just introduce a Sleep into the
code executed by the ThreadProc and you correctly simulate the long
running request.

3. When you call HSE_REQ_IO_COMPLETION to set up the async completion
function, the last parameter, lpdwContext, is a pointer value which
will be persisted and provided to the registered
PFN_HSE_IO_COMPLETION_CALLBACK as PVOID pContext. This completely
mirrors how Win32 CreateThread and ThreadProc work. Now, IIS only
allows one outstanding async IO request, so make sure you don't
violate that.

If you don't mind me asking -- how exactly are you doing async IO?
Because it is kinda hard to do it correctly without #3.

You have many parts of asynchronous IO correct, but your polling
approach to introduce request delay is really suspect, as is your
question about how to pass pointer across the async call. I suspect
your issue with ConnID stem from one or both of these suspect areas...


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//




On Jan 14, 5:35 am, Ibrahim Shahin
 wrote:
> thx, how could iis reuse it while the other connection is still active ??,> then how iis will differ between active requests which have the same connID ??
>
>
>
> "Ian" wrote:
> > AFAIK connID is just a pointer to a block of memory, and IIS re-uses
> > these in order to improve performance. So even if its a connID you've
> > seen before, it doesn't mean its the same physical socket connection.
>
> > It sounds like you are using some kind of polling for the thread pool,
> > which generally you should avoid. Use one of the WaitFor* APIs,  e.g.
> > WaitForSingleObject, to wait for completion of an external task, e.g.
> > another process.
>
> > Ian
>
> > Ibrahim Shahin wrote:
> > > thx for your reply,
>
> > > 1st, i'm not using a normal http client (browser) like IE, i knew that HTTP
> > > 1.1 standards force the 2 connections limitation for a certain server and
> > > also knew the iis's 10 conn.(s) limit, but i do coded a simple client using
> > > winsocks that do multiple requests to the iis server using http protocol, so
> > > why did iis reuse the connID ?.
>
> > > 2nd, about my thread-pool design, the delay will not accur inside my dll's
> > > threads but it'll carried out in another process, so all what i need is
> > > checking for the finished tasks and send response back to the client using
> > > writeclient().
>
> > > 3rd, about the async operations, if i will allocate some sort of data inside
> > > my dll (not through iis) per each request, so how could i pass a pointer for
> > > it to the callback function ?.
>
> > > i hope that the scenario is more clear now, and if u need an explanation for
> > > anything after that i can add some blocks of code later.
>
> > > "David Wang" wrote:
>
> > >> On Jan 13, 3:07 pm, Ibrahim Shahin
> > >>  wrote:
> > >>> dear all,
>
> > >>>  i'm working on developing an extension for the purpose of some long-timed
> > >>> requests, so after writing the main blocks of the code using VC.0  MFC
> > >>> that includes a separate thread pool & some shared datastructures with simple
> > >>> sync mechanism, my test is as follows:
>
> > >>> 1- return HSE_STATUS_PENDING to the server
>
> > >>> 2- pass pCtxt to my thread pool
>
> > >>> 3- threadpool will check periodically for active connections, and when a
> > >>> connection reaches a certain time (eg: 30 sec- 2 min) it uses writeclient()
> > >>> for sending reply then it call ServerSupportFunction() with
> > >>> HSE_REQ_DONE_WITH_SESSION and removes pCtxt from my active conn.(s)' list
>
> > >>> 4- the client that i used for testing do open multiple connections
> > >>> requesting ext.'s dll from the server, so i can detect number of simaltenious
> > >>> conn.(s)
>
> > >>> but i found something strange, the client can only have 2 simalt. conn.(s)
> > >>> active with iis at a time, and any new request come from the same ip, the iis
> > >>> reuse one of the 2 active conn.(s)' connID to be used with it, even i think
> > >>> it leaves all the sockets opening (old and new) but reuse connID which is
> > >>> used by writeclient(), so in my test, the last 2 conn.(s) recieved all the
> > >>> sent data to the opened connections.
>
> > >>> if this is a limitation of win xp iis, so how could this operate if the
> > >>> requests are coming from behind nat or proxy.
>
> > >>> another question is about async callbacks, if i used async writeclient() for
> > >>> example, can i access any shared data inside dll from it or i can use only
> > >>> pECB's included functions pointers (as callback is not running actually in my
> > >>> dll ??), seems no to me (accessing shared data failed) !!!, and how could i
> > >>> use the pContext arg of callback, should i pass the pCtxt first when i call
> > >>> ServerSupportFunction() with HSE_REQ_IO_COMPLETION as the last parameter.
>
> > >>>  thx,
>
> > >>> with regards
>
> > >> That two connection limit seems to come from your test client -- for
> > >> example, WinInet (what IE uses) has such a limit against a single
> > >> server.
>
> > >> However, IIS 5.1 on XP Pro does have a 10 connection limit, so it will
> > >> not be ideal for you to test your particular behavior even when you
> > >> unblock the test client.
>
> > >> The way you describe your testing of long async requests is strange.
> > >> All you need is a thread pool whose threadproc sleeps 30 sec to 2
> > >> minutes before using the ECB to WriteClient and DoneWithSession. There
> > >> is no need for threadpool to check for active connections. Makes me
> > >> wonder if you have a correctly written Threadpool.
>
> > >> Please show the code illustrating what you are talking about (put in
> > >> comments where you are having questions/problems). I cannot understand
> > >> how exactly you are trying to "share data" and when you are trying to> > >> "use pContext". What you want to do is possible -- it is a matter of
> > >> the right sequence of code, but I can't tell what your current
> > >> sequence is.
>
> > >> //David
> > >>http://w3-4u.blogspot.com
> > >>http://blogs.msdn.com/David.Wang
> > >> //- Hide quoted text -
>
> - Show quoted text -

////

static count = 0;
static LinkedList mLst;

BOOL CMyExtension::GetExtensionVersion(HSE_VERSION_INFO* pVer)
{
	//start threads
}

DWORD CMyExtension::HttpExtensionProc(EXTENSION_CONTROL_BLOCK *pECB)
{
	DWORD  dwResult = CHttpServer::HttpExtensionProc(pECB);
	if(dwResult == HSE_STATUS_SUCCESS)
	  return HSE_STATUS_PENDING;
	else
	  return dwResult;
}

void CMyExtension::Default(CHttpServerContext* pCtxt)
{
	//
	mLst.Add(pCtxt);
	//
}

static void ThreadProc()
{
	//
	//wait for finished tasks (in my test, i simulated the time to be fixed for 
about 30 sec)
	//if task is finished
	char data[256];
	sprintf(data, "sending to no: %d - connID: %d\r\n", ++count, 
task.pCtxt->m_pECB->ConnID);
	DWORD sz = strlen(data);
	task.pCtxt->WriteClient(data, &sz); //write back response
	task.pCtxt->ServerSupportFunction(HSE_REQ_DONE_WITH_SESSION, NULL, NULL, 
NULL);
	mLst.Remove(task.pCtxt);
	//
}

if i used a 3 instances of my client to be opened quicly after each other 
before the 30 sec elapsed

the output will be:

1st:

will pend on sock.recv() and will not receive anything

2nd:

sending to no: 2 - connID: 11111011

3rd:

sending to no: 1 - connID: 11111001
//sending to no: 3 - connID: 11111001 //this will not be sent coz of 
DONE_WITH_SESSION of the 1st

"David Wang" wrote:

> On Jan 13, 3:07 pm, Ibrahim Shahin
>  wrote:
> > dear all,
> >
> >  i'm working on developing an extension for the purpose of some long-timed
> > requests, so after writing the main blocks of the code using VC++6.0 + MFC
> > that includes a separate thread pool & some shared datastructures with simple
> > sync mechanism, my test is as follows:
> >
> > 1- return HSE_STATUS_PENDING to the server
> >
> > 2- pass pCtxt to my thread pool
> >
> > 3- threadpool will check periodically for active connections, and when a
> > connection reaches a certain time (eg: 30 sec- 2 min) it uses writeclient()
> > for sending reply then it call ServerSupportFunction() with
> > HSE_REQ_DONE_WITH_SESSION and removes pCtxt from my active conn.(s)' list
> >
> > 4- the client that i used for testing do open multiple connections
> > requesting ext.'s dll from the server, so i can detect number of simaltenious
> > conn.(s)
> >
> > but i found something strange, the client can only have 2 simalt. conn.(s)
> > active with iis at a time, and any new request come from the same ip, the iis
> > reuse one of the 2 active conn.(s)' connID to be used with it, even i think
> > it leaves all the sockets opening (old and new) but reuse connID which is
> > used by writeclient(), so in my test, the last 2 conn.(s) recieved all the
> > sent data to the opened connections.
> >
> > if this is a limitation of win xp iis, so how could this operate if the
> > requests are coming from behind nat or proxy.
> >
> > another question is about async callbacks, if i used async writeclient() for
> > example, can i access any shared data inside dll from it or i can use only
> > pECB's included functions pointers (as callback is not running actually in my
> > dll ??), seems no to me (accessing shared data failed) !!!, and how could i
> > use the pContext arg of callback, should i pass the pCtxt first when i call
> > ServerSupportFunction() with HSE_REQ_IO_COMPLETION as the last parameter.
> >
> >  thx,
> >
> > with regards
> 
> 
> That two connection limit seems to come from your test client -- for
> example, WinInet (what IE uses) has such a limit against a single
> server.
> 
> However, IIS 5.1 on XP Pro does have a 10 connection limit, so it will
> not be ideal for you to test your particular behavior even when you
> unblock the test client.
> 
> The way you describe your testing of long async requests is strange.
> All you need is a thread pool whose threadproc sleeps 30 sec to 2
> minutes before using the ECB to WriteClient and DoneWithSession. There
> is no need for threadpool to check for active connections. Makes me
> wonder if you have a correctly written Threadpool.
> 
> Please show the code illustrating what you are talking about (put in
> comments where you are having questions/problems). I cannot understand
> how exactly you are trying to "share data" and when you are trying to
> "use pContext". What you want to do is possible -- it is a matter of
> the right sequence of code, but I can't tell what your current
> sequence is.
> 
> 
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>

i had added some code from 5 min, i didn't know if you red it or not, thx

"David Wang" wrote:

> 1. You should consider the ConnID value as opaque. If you do your part
> correctly, IIS will do its part correctly. As for why ConnID is re-
> used -- IIS is an optimized server that uses allocation caching to
> avoiding hitting the heap -- and ConnID comes out of that cache --
> thus if your code acts correctly, IIS will give you the right values.
> 
> 2. That sounds like a "polling" approach to introduce delay, which you
> should avoid. Like I said, it is really easy to simulate a "long
> running asynchronous operation" -- just introduce a Sleep into the
> code executed by the ThreadProc and you correctly simulate the long
> running request.
> 
> 3. When you call HSE_REQ_IO_COMPLETION to set up the async completion
> function, the last parameter, lpdwContext, is a pointer value which
> will be persisted and provided to the registered
> PFN_HSE_IO_COMPLETION_CALLBACK as PVOID pContext. This completely
> mirrors how Win32 CreateThread and ThreadProc work. Now, IIS only
> allows one outstanding async IO request, so make sure you don't
> violate that.
> 
> If you don't mind me asking -- how exactly are you doing async IO?
> Because it is kinda hard to do it correctly without #3.
> 
> You have many parts of asynchronous IO correct, but your polling
> approach to introduce request delay is really suspect, as is your
> question about how to pass pointer across the async call. I suspect
> your issue with ConnID stem from one or both of these suspect areas...
> 
> 
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
> 
> 
> 
> 
> On Jan 14, 5:35 am, Ibrahim Shahin
>  wrote:
> > thx, how could iis reuse it while the other connection is still active ??,
> > then how iis will differ between active requests which have the same connID ??
> >
> >
> >
> > "Ian" wrote:
> > > AFAIK connID is just a pointer to a block of memory, and IIS re-uses
> > > these in order to improve performance. So even if its a connID you've
> > > seen before, it doesn't mean its the same physical socket connection.
> >
> > > It sounds like you are using some kind of polling for the thread pool,
> > > which generally you should avoid. Use one of the WaitFor* APIs,  e.g.
> > > WaitForSingleObject, to wait for completion of an external task, e.g.
> > > another process.
> >
> > > Ian
> >
> > > Ibrahim Shahin wrote:
> > > > thx for your reply,
> >
> > > > 1st, i'm not using a normal http client (browser) like IE, i knew that HTTP
> > > > 1.1 standards force the 2 connections limitation for a certain server and
> > > > also knew the iis's 10 conn.(s) limit, but i do coded a simple client using
> > > > winsocks that do multiple requests to the iis server using http protocol, so
> > > > why did iis reuse the connID ?.
> >
> > > > 2nd, about my thread-pool design, the delay will not accur inside my dll's
> > > > threads but it'll carried out in another process, so all what i need is
> > > > checking for the finished tasks and send response back to the client using
> > > > writeclient().
> >
> > > > 3rd, about the async operations, if i will allocate some sort of data inside
> > > > my dll (not through iis) per each request, so how could i pass a pointer for
> > > > it to the callback function ?.
> >
> > > > i hope that the scenario is more clear now, and if u need an explanation for
> > > > anything after that i can add some blocks of code later.
> >
> > > > "David Wang" wrote:
> >
> > > >> On Jan 13, 3:07 pm, Ibrahim Shahin
> > > >>  wrote:
> > > >>> dear all,
> >
> > > >>>  i'm working on developing an extension for the purpose of some long-timed
> > > >>> requests, so after writing the main blocks of the code using VC++6.0 + MFC
> > > >>> that includes a separate thread pool & some shared datastructures with simple
> > > >>> sync mechanism, my test is as follows:
> >
> > > >>> 1- return HSE_STATUS_PENDING to the server
> >
> > > >>> 2- pass pCtxt to my thread pool
> >
> > > >>> 3- threadpool will check periodically for active connections, and when a
> > > >>> connection reaches a certain time (eg: 30 sec- 2 min) it uses writeclient()
> > > >>> for sending reply then it call ServerSupportFunction() with
> > > >>> HSE_REQ_DONE_WITH_SESSION and removes pCtxt from my active conn.(s)' list
> >
> > > >>> 4- the client that i used for testing do open multiple connections
> > > >>> requesting ext.'s dll from the server, so i can detect number of simaltenious
> > > >>> conn.(s)
> >
> > > >>> but i found something strange, the client can only have 2 simalt. conn.(s)
> > > >>> active with iis at a time, and any new request come from the same ip, the iis
> > > >>> reuse one of the 2 active conn.(s)' connID to be used with it, even i think
> > > >>> it leaves all the sockets opening (old and new) but reuse connID which is
> > > >>> used by writeclient(), so in my test, the last 2 conn.(s) recieved all the
> > > >>> sent data to the opened connections.
> >
> > > >>> if this is a limitation of win xp iis, so how could this operate if the
> > > >>> requests are coming from behind nat or proxy.
> >
> > > >>> another question is about async callbacks, if i used async writeclient() for
> > > >>> example, can i access any shared data inside dll from it or i can use only
> > > >>> pECB's included functions pointers (as callback is not running actually in my
> > > >>> dll ??), seems no to me (accessing shared data failed) !!!, and how could i
> > > >>> use the pContext arg of callback, should i pass the pCtxt first when i call
> > > >>> ServerSupportFunction() with HSE_REQ_IO_COMPLETION as the last parameter.
> >
> > > >>>  thx,
> >
> > > >>> with regards
> >
> > > >> That two connection limit seems to come from your test client -- for
> > > >> example, WinInet (what IE uses) has such a limit against a single
> > > >> server.
> >
> > > >> However, IIS 5.1 on XP Pro does have a 10 connection limit, so it will
> > > >> not be ideal for you to test your particular behavior even when you
> > > >> unblock the test client.
> >
> > > >> The way you describe your testing of long async requests is strange.
> > > >> All you need is a thread pool whose threadproc sleeps 30 sec to 2
> > > >> minutes before using the ECB to WriteClient and DoneWithSession. There
> > > >> is no need for threadpool to check for active connections. Makes me
> > > >> wonder if you have a correctly written Threadpool.
> >
> > > >> Please show the code illustrating what you are talking about (put in
> > > >> comments where you are having questions/problems). I cannot understand
> > > >> how exactly you are trying to "share data" and when you are trying to
> > > >> "use pContext". What you want to do is possible -- it is a matter of
> > > >> the right sequence of code, but I can't tell what your current
> > > >> sequence is.
> >
> > > >> //David
> > > >>http://w3-4u.blogspot.com
> > > >>http://blogs.msdn.com/David.Wang
> > > >> //- Hide quoted text -
> >
> > - Show quoted text -
> 
>

How is each ECB being passed to ThreadProc for every request into
HttpExtensionProc?


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//



On Jan 14, 3:41 pm, Ibrahim Shahin
 wrote:
> ////
>
> static count = 0;
> static LinkedList mLst;
>
> BOOL CMyExtension::GetExtensionVersion(HSE_VERSION_INFO* pVer)
> {
>         //start threads
>
> }
>
> DWORD CMyExtension::HttpExtensionProc(EXTENSION_CONTROL_BLOCK *pECB)
> {
>         DWORD  dwResult = CHttpServer::HttpExtensionProc(pECB)>         if(dwResult == HSE_STATUS_SUCCESS)
>           return HSE_STATUS_PENDING;
>         else
>           return dwResult;
>
> }
>
> void CMyExtension::Default(CHttpServerContext* pCtxt)
> {
>         //
>         mLst.Add(pCtxt);
>         //
>
> }
>
> static void ThreadProc()
> {
>         //
>         //wait for finished tasks (in my test, i simulated the time to be fixed for
> about 30 sec)
>         //if task is finished
>         char data[256];
>         sprintf(data, "sending to no: %d - connID: %d\r\n", 流⺞,
> task.pCtxt->m_pECB->ConnID);
>         DWORD sz = strlen(data);
>         task.pCtxt->WriteClient(data, &sz); //write back response
>         task.pCtxt->ServerSupportFunction(HSE_REQ_DONE_WITH_SESSION, NULL, NULL,
> NULL);
>         mLst.Remove(task.pCtxt);
>         //
>
> }
>
> if i used a 3 instances of my client to be opened quicly after each other
> before the 30 sec elapsed
>
> the output will be:
>
> 1st:
>
> will pend on sock.recv() and will not receive anything
>
> 2nd:
>
> sending to no: 2 - connID: 11111011
>
> 3rd:
>
> sending to no: 1 - connID: 11111001
> //sending to no: 3 - connID: 11111001 //this will not be sent coz of
> DONE_WITH_SESSION of the 1st
>
>
>
> "David Wang" wrote:
> > On Jan 13, 3:07 pm, Ibrahim Shahin
> >  wrote:
> > > dear all,
>
> > >  i'm working on developing an extension for the purpose of some long-timed
> > > requests, so after writing the main blocks of the code using VC.0  MFC
> > > that includes a separate thread pool & some shared datastructures with simple
> > > sync mechanism, my test is as follows:
>
> > > 1- return HSE_STATUS_PENDING to the server
>
> > > 2- pass pCtxt to my thread pool
>
> > > 3- threadpool will check periodically for active connections, and when a
> > > connection reaches a certain time (eg: 30 sec- 2 min) it uses writeclient()
> > > for sending reply then it call ServerSupportFunction() with
> > > HSE_REQ_DONE_WITH_SESSION and removes pCtxt from my active conn.(s)' list
>
> > > 4- the client that i used for testing do open multiple connections
> > > requesting ext.'s dll from the server, so i can detect number of simaltenious
> > > conn.(s)
>
> > > but i found something strange, the client can only have 2 simalt. conn.(s)
> > > active with iis at a time, and any new request come from the same ip, the iis
> > > reuse one of the 2 active conn.(s)' connID to be used with it, even i think
> > > it leaves all the sockets opening (old and new) but reuse connID which is
> > > used by writeclient(), so in my test, the last 2 conn.(s) recieved all the
> > > sent data to the opened connections.
>
> > > if this is a limitation of win xp iis, so how could this operate if the
> > > requests are coming from behind nat or proxy.
>
> > > another question is about async callbacks, if i used async writeclient() for
> > > example, can i access any shared data inside dll from it or i can use only
> > > pECB's included functions pointers (as callback is not running actually in my
> > > dll ??), seems no to me (accessing shared data failed) !!!, and how could i
> > > use the pContext arg of callback, should i pass the pCtxt first when i call
> > > ServerSupportFunction() with HSE_REQ_IO_COMPLETION as the last parameter.
>
> > >  thx,
>
> > > with regards
>
> > That two connection limit seems to come from your test client -- for
> > example, WinInet (what IE uses) has such a limit against a single
> > server.
>
> > However, IIS 5.1 on XP Pro does have a 10 connection limit, so it will
> > not be ideal for you to test your particular behavior even when you
> > unblock the test client.
>
> > The way you describe your testing of long async requests is strange.
> > All you need is a thread pool whose threadproc sleeps 30 sec to 2
> > minutes before using the ECB to WriteClient and DoneWithSession. There
> > is no need for threadpool to check for active connections. Makes me
> > wonder if you have a correctly written Threadpool.
>
> > Please show the code illustrating what you are talking about (put in
> > comments where you are having questions/problems). I cannot understand
> > how exactly you are trying to "share data" and when you are trying to
> > "use pContext". What you want to do is possible -- it is a matter of
> > the right sequence of code, but I can't tell what your current
> > sequence is.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //- Hide quoted text -
>
> - Show quoted text -

through the linked list, in my simulation, i have added a timestamp (request 
start) to each request and add a struct containing both of pCtxt and 
timestamp to the list, then threadproc get requests that have been idle for 
30 sec.

"David Wang" wrote:

> How is each ECB being passed to ThreadProc for every request into
> HttpExtensionProc?
> 
> 
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
> 
> 
> 
> On Jan 14, 3:41 pm, Ibrahim Shahin
>  wrote:
> > ////
> >
> > static count = 0;
> > static LinkedList mLst;
> >
> > BOOL CMyExtension::GetExtensionVersion(HSE_VERSION_INFO* pVer)
> > {
> >         //start threads
> >
> > }
> >
> > DWORD CMyExtension::HttpExtensionProc(EXTENSION_CONTROL_BLOCK *pECB)
> > {
> >         DWORD  dwResult = CHttpServer::HttpExtensionProc(pECB);
> >         if(dwResult == HSE_STATUS_SUCCESS)
> >           return HSE_STATUS_PENDING;
> >         else
> >           return dwResult;
> >
> > }
> >
> > void CMyExtension::Default(CHttpServerContext* pCtxt)
> > {
> >         //
> >         mLst.Add(pCtxt);
> >         //
> >
> > }
> >
> > static void ThreadProc()
> > {
> >         //
> >         //wait for finished tasks (in my test, i simulated the time to be fixed for
> > about 30 sec)
> >         //if task is finished
> >         char data[256];
> >         sprintf(data, "sending to no: %d - connID: %d\r\n", ++count,
> > task.pCtxt->m_pECB->ConnID);
> >         DWORD sz = strlen(data);
> >         task.pCtxt->WriteClient(data, &sz); //write back response
> >         task.pCtxt->ServerSupportFunction(HSE_REQ_DONE_WITH_SESSION, NULL, NULL,
> > NULL);
> >         mLst.Remove(task.pCtxt);
> >         //
> >
> > }
> >
> > if i used a 3 instances of my client to be opened quicly after each other
> > before the 30 sec elapsed
> >
> > the output will be:
> >
> > 1st:
> >
> > will pend on sock.recv() and will not receive anything
> >
> > 2nd:
> >
> > sending to no: 2 - connID: 11111011
> >
> > 3rd:
> >
> > sending to no: 1 - connID: 11111001
> > //sending to no: 3 - connID: 11111001 //this will not be sent coz of
> > DONE_WITH_SESSION of the 1st
> >
> >
> >
> > "David Wang" wrote:
> > > On Jan 13, 3:07 pm, Ibrahim Shahin
> > >  wrote:
> > > > dear all,
> >
> > > >  i'm working on developing an extension for the purpose of some long-timed
> > > > requests, so after writing the main blocks of the code using VC++6.0 + MFC
> > > > that includes a separate thread pool & some shared datastructures with simple
> > > > sync mechanism, my test is as follows:
> >
> > > > 1- return HSE_STATUS_PENDING to the server
> >
> > > > 2- pass pCtxt to my thread pool
> >
> > > > 3- threadpool will check periodically for active connections, and when a
> > > > connection reaches a certain time (eg: 30 sec- 2 min) it uses writeclient()
> > > > for sending reply then it call ServerSupportFunction() with
> > > > HSE_REQ_DONE_WITH_SESSION and removes pCtxt from my active conn.(s)' list
> >
> > > > 4- the client that i used for testing do open multiple connections
> > > > requesting ext.'s dll from the server, so i can detect number of simaltenious
> > > > conn.(s)
> >
> > > > but i found something strange, the client can only have 2 simalt. conn..(s)
> > > > active with iis at a time, and any new request come from the same ip, the iis
> > > > reuse one of the 2 active conn.(s)' connID to be used with it, even i think
> > > > it leaves all the sockets opening (old and new) but reuse connID which is
> > > > used by writeclient(), so in my test, the last 2 conn.(s) recieved all the
> > > > sent data to the opened connections.
> >
> > > > if this is a limitation of win xp iis, so how could this operate if the
> > > > requests are coming from behind nat or proxy.
> >
> > > > another question is about async callbacks, if i used async writeclient() for
> > > > example, can i access any shared data inside dll from it or i can use only
> > > > pECB's included functions pointers (as callback is not running actually in my
> > > > dll ??), seems no to me (accessing shared data failed) !!!, and how could i
> > > > use the pContext arg of callback, should i pass the pCtxt first when i call
> > > > ServerSupportFunction() with HSE_REQ_IO_COMPLETION as the last parameter.
> >
> > > >  thx,
> >
> > > > with regards
> >
> > > That two connection limit seems to come from your test client -- for
> > > example, WinInet (what IE uses) has such a limit against a single
> > > server.
> >
> > > However, IIS 5.1 on XP Pro does have a 10 connection limit, so it will
> > > not be ideal for you to test your particular behavior even when you
> > > unblock the test client.
> >
> > > The way you describe your testing of long async requests is strange.
> > > All you need is a thread pool whose threadproc sleeps 30 sec to 2
> > > minutes before using the ECB to WriteClient and DoneWithSession. There
> > > is no need for threadpool to check for active connections. Makes me
> > > wonder if you have a correctly written Threadpool.
> >
> > > Please show the code illustrating what you are talking about (put in
> > > comments where you are having questions/problems). I cannot understand
> > > how exactly you are trying to "share data" and when you are trying to
> > > "use pContext". What you want to do is possible -- it is a matter of
> > > the right sequence of code, but I can't tell what your current
> > > sequence is.
> >
> > > //David
> > >http://w3-4u.blogspot.com
> > >http://blogs.msdn.com/David.Wang
> > > //- Hide quoted text -
> >
> > - Show quoted text -
> 
>

Ok, that's the part I don't understand. Why is some other thread
dispatching requests to ThreadProc. Because if it controls dispatching
requests, it also controls the strange "behavior" that you observe.

Usually, I expect dispatch of the ECB to the ThreadPool to happen
within HttpExtensionProc. The ThreadPool immediately finds an
available pool Thread (either threads are waiting on the ThreadPool's
"outstanding queue", or ThreadPool tracks available threads and
immediately dispatches). At the time of dispatch, ThreadPool hands the
ECB to the Thread's ThreadProc.

No shared data of any sort is needed to pass async data around.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//



On Jan 14, 4:29 pm, Ibrahim Shahin
 wrote:
> through the linked list, in my simulation, i have added a timestamp (request
> start) to each request and add a struct containing both of pCtxt and
> timestamp to the list, then threadproc get requests that have been idle for
> 30 sec.
>
>
>
> "David Wang" wrote:
> > How is each ECB being passed to ThreadProc for every request into
> > HttpExtensionProc?
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> > On Jan 14, 3:41 pm, Ibrahim Shahin
> >  wrote:
> > > ////
>
> > > static count = 0;
> > > static LinkedList mLst;
>
> > > BOOL CMyExtension::GetExtensionVersion(HSE_VERSION_INFO* pVer)
> > > {
> > >         //start threads
>
> > > }
>
> > > DWORD CMyExtension::HttpExtensionProc(EXTENSION_CONTROL_BLOCK *pECB)
> > > {
> > >         DWORD  dwResult = CHttpServer::HttpExtensionProc(pECB);
> > >         if(dwResult == HSE_STATUS_SUCCESS)
> > >           return HSE_STATUS_PENDING;
> > >         else
> > >           return dwResult;
>
> > > }
>
> > > void CMyExtension::Default(CHttpServerContext* pCtxt)
> > > {
> > >         //
> > >         mLst.Add(pCtxt);
> > >         //
>
> > > }
>
> > > static void ThreadProc()
> > > {
> > >         //
> > >         //wait for finished tasks (in my test, i simulated the time to be fixed for
> > > about 30 sec)
> > >         //if task is finished
> > >         char data[256];
> > >         sprintf(data, "sending to no: %d - connID: %d\r\n", 流⺞,
> > > task.pCtxt->m_pECB->ConnID);
> > >         DWORD sz = strlen(data);
> > >         task.pCtxt->WriteClient(data, &sz); //write back response
> > >         task.pCtxt->ServerSupportFunction(HSE_REQ_DONE_WITH_SESSION, NULL, NULL,
> > > NULL);
> > >         mLst.Remove(task.pCtxt);
> > >         //
>
> > > }
>
> > > if i used a 3 instances of my client to be opened quicly after each other
> > > before the 30 sec elapsed
>
> > > the output will be:
>
> > > 1st:
>
> > > will pend on sock.recv() and will not receive anything
>
> > > 2nd:
>
> > > sending to no: 2 - connID: 11111011
>
> > > 3rd:
>
> > > sending to no: 1 - connID: 11111001
> > > //sending to no: 3 - connID: 11111001 //this will not be sent coz of
> > > DONE_WITH_SESSION of the 1st
>
> > > "David Wang" wrote:
> > > > On Jan 13, 3:07 pm, Ibrahim Shahin
> > > >  wrote:
> > > > > dear all,
>
> > > > >  i'm working on developing an extension for the purpose of some long-timed
> > > > > requests, so after writing the main blocks of the code using VC.0  MFC
> > > > > that includes a separate thread pool & some shared datastructures with simple
> > > > > sync mechanism, my test is as follows:
>
> > > > > 1- return HSE_STATUS_PENDING to the server
>
> > > > > 2- pass pCtxt to my thread pool
>
> > > > > 3- threadpool will check periodically for active connections, and when a
> > > > > connection reaches a certain time (eg: 30 sec- 2 min) it uses writeclient()
> > > > > for sending reply then it call ServerSupportFunction() with
> > > > > HSE_REQ_DONE_WITH_SESSION and removes pCtxt from my active conn.(s)' list
>
> > > > > 4- the client that i used for testing do open multiple connections> > > > > requesting ext.'s dll from the server, so i can detect number of simaltenious
> > > > > conn.(s)
>
> > > > > but i found something strange, the client can only have 2 simalt. conn..(s)
> > > > > active with iis at a time, and any new request come from the same ip, the iis
> > > > > reuse one of the 2 active conn.(s)' connID to be used with it, even i think
> > > > > it leaves all the sockets opening (old and new) but reuse connID which is
> > > > > used by writeclient(), so in my test, the last 2 conn.(s) recieved all the
> > > > > sent data to the opened connections.
>
> > > > > if this is a limitation of win xp iis, so how could this operate if the
> > > > > requests are coming from behind nat or proxy.
>
> > > > > another question is about async callbacks, if i used async writeclient() for
> > > > > example, can i access any shared data inside dll from it or i can use only
> > > > > pECB's included functions pointers (as callback is not running actually in my
> > > > > dll ??), seems no to me (accessing shared data failed) !!!, and how could i
> > > > > use the pContext arg of callback, should i pass the pCtxt first when i call
> > > > > ServerSupportFunction() with HSE_REQ_IO_COMPLETION as the last parameter.
>
> > > > >  thx,
>
> > > > > with regards
>
> > > > That two connection limit seems to come from your test client -- for> > > > example, WinInet (what IE uses) has such a limit against a single
> > > > server.
>
> > > > However, IIS 5.1 on XP Pro does have a 10 connection limit, so it will
> > > > not be ideal for you to test your particular behavior even when you
> > > > unblock the test client.
>
> > > > The way you describe your testing of long async requests is strange.> > > > All you need is a thread pool whose threadproc sleeps 30 sec to 2
> > > > minutes before using the ECB to WriteClient and DoneWithSession. There
> > > > is no need for threadpool to check for active connections. Makes me
> > > > wonder if you have a correctly written Threadpool.
>
> > > > Please show the code illustrating what you are talking about (put in> > > > comments where you are having questions/problems). I cannot understand
> > > > how exactly you are trying to "share data" and when you are trying to
> > > > "use pContext". What you want to do is possible -- it is a matter of> > > > the right sequence of code, but I can't tell what your current
> > > > sequence is.
>
> > > > //David
> > > >http://w3-4u.blogspot.com
> > > >http://blogs.msdn.com/David.Wang
> > > > //- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

because as i mentioned b4 the delay will not come from any processing inside 
my dll but the processing will accur in another process, so my threadpool 
will act like a collection of threads waiting on a completion-port that have 
multiple async WSARecv() calls initiated on it.

"David Wang" wrote:

> Ok, that's the part I don't understand. Why is some other thread
> dispatching requests to ThreadProc. Because if it controls dispatching
> requests, it also controls the strange "behavior" that you observe.
> 
> Usually, I expect dispatch of the ECB to the ThreadPool to happen
> within HttpExtensionProc. The ThreadPool immediately finds an
> available pool Thread (either threads are waiting on the ThreadPool's
> "outstanding queue", or ThreadPool tracks available threads and
> immediately dispatches). At the time of dispatch, ThreadPool hands the
> ECB to the Thread's ThreadProc.
> 
> No shared data of any sort is needed to pass async data around.
> 
> 
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
> 
> 
> 
> On Jan 14, 4:29 pm, Ibrahim Shahin
>  wrote:
> > through the linked list, in my simulation, i have added a timestamp (request
> > start) to each request and add a struct containing both of pCtxt and
> > timestamp to the list, then threadproc get requests that have been idle for
> > 30 sec.
> >
> >
> >
> > "David Wang" wrote:
> > > How is each ECB being passed to ThreadProc for every request into
> > > HttpExtensionProc?
> >
> > > //David
> > >http://w3-4u.blogspot.com
> > >http://blogs.msdn.com/David.Wang
> > > //
> >
> > > On Jan 14, 3:41 pm, Ibrahim Shahin
> > >  wrote:
> > > > ////
> >
> > > > static count = 0;
> > > > static LinkedList mLst;
> >
> > > > BOOL CMyExtension::GetExtensionVersion(HSE_VERSION_INFO* pVer)
> > > > {
> > > >         //start threads
> >
> > > > }
> >
> > > > DWORD CMyExtension::HttpExtensionProc(EXTENSION_CONTROL_BLOCK *pECB)
> > > > {
> > > >         DWORD  dwResult = CHttpServer::HttpExtensionProc(pECB);
> > > >         if(dwResult == HSE_STATUS_SUCCESS)
> > > >           return HSE_STATUS_PENDING;
> > > >         else
> > > >           return dwResult;
> >
> > > > }
> >
> > > > void CMyExtension::Default(CHttpServerContext* pCtxt)
> > > > {
> > > >         //
> > > >         mLst.Add(pCtxt);
> > > >         //
> >
> > > > }
> >
> > > > static void ThreadProc()
> > > > {
> > > >         //
> > > >         //wait for finished tasks (in my test, i simulated the time to be fixed for
> > > > about 30 sec)
> > > >         //if task is finished
> > > >         char data[256];
> > > >         sprintf(data, "sending to no: %d - connID: %d\r\n", ++count,
> > > > task.pCtxt->m_pECB->ConnID);
> > > >         DWORD sz = strlen(data);
> > > >         task.pCtxt->WriteClient(data, &sz); //write back response
> > > >         task.pCtxt->ServerSupportFunction(HSE_REQ_DONE_WITH_SESSION, NULL, NULL,
> > > > NULL);
> > > >         mLst.Remove(task.pCtxt);
> > > >         //
> >
> > > > }
> >
> > > > if i used a 3 instances of my client to be opened quicly after each other
> > > > before the 30 sec elapsed
> >
> > > > the output will be:
> >
> > > > 1st:
> >
> > > > will pend on sock.recv() and will not receive anything
> >
> > > > 2nd:
> >
> > > > sending to no: 2 - connID: 11111011
> >
> > > > 3rd:
> >
> > > > sending to no: 1 - connID: 11111001
> > > > //sending to no: 3 - connID: 11111001 //this will not be sent coz of
> > > > DONE_WITH_SESSION of the 1st
> >
> > > > "David Wang" wrote:
> > > > > On Jan 13, 3:07 pm, Ibrahim Shahin
> > > > >  wrote:
> > > > > > dear all,
> >
> > > > > >  i'm working on developing an extension for the purpose of some long-timed
> > > > > > requests, so after writing the main blocks of the code using VC++6..0 + MFC
> > > > > > that includes a separate thread pool & some shared datastructures with simple
> > > > > > sync mechanism, my test is as follows:
> >
> > > > > > 1- return HSE_STATUS_PENDING to the server
> >
> > > > > > 2- pass pCtxt to my thread pool
> >
> > > > > > 3- threadpool will check periodically for active connections, and when a
> > > > > > connection reaches a certain time (eg: 30 sec- 2 min) it uses writeclient()
> > > > > > for sending reply then it call ServerSupportFunction() with
> > > > > > HSE_REQ_DONE_WITH_SESSION and removes pCtxt from my active conn.(s)' list
> >
> > > > > > 4- the client that i used for testing do open multiple connections
> > > > > > requesting ext.'s dll from the server, so i can detect number of simaltenious
> > > > > > conn.(s)
> >
> > > > > > but i found something strange, the client can only have 2 simalt. conn..(s)
> > > > > > active with iis at a time, and any new request come from the same ip, the iis
> > > > > > reuse one of the 2 active conn.(s)' connID to be used with it, even i think
> > > > > > it leaves all the sockets opening (old and new) but reuse connID which is
> > > > > > used by writeclient(), so in my test, the last 2 conn.(s) recieved all the
> > > > > > sent data to the opened connections.
> >
> > > > > > if this is a limitation of win xp iis, so how could this operate if the
> > > > > > requests are coming from behind nat or proxy.
> >
> > > > > > another question is about async callbacks, if i used async writeclient() for
> > > > > > example, can i access any shared data inside dll from it or i can use only
> > > > > > pECB's included functions pointers (as callback is not running actually in my
> > > > > > dll ??), seems no to me (accessing shared data failed) !!!, and how could i
> > > > > > use the pContext arg of callback, should i pass the pCtxt first when i call
> > > > > > ServerSupportFunction() with HSE_REQ_IO_COMPLETION as the last parameter.
> >
> > > > > >  thx,
> >
> > > > > > with regards
> >
> > > > > That two connection limit seems to come from your test client -- for
> > > > > example, WinInet (what IE uses) has such a limit against a single
> > > > > server.
> >
> > > > > However, IIS 5.1 on XP Pro does have a 10 connection limit, so it will
> > > > > not be ideal for you to test your particular behavior even when you
> > > > > unblock the test client.
> >
> > > > > The way you describe your testing of long async requests is strange.
> > > > > All you need is a thread pool whose threadproc sleeps 30 sec to 2
> > > > > minutes before using the ECB to WriteClient and DoneWithSession. There
> > > > > is no need for threadpool to check for active connections. Makes me
> > > > > wonder if you have a correctly written Threadpool.
> >
> > > > > Please show the code illustrating what you are talking about (put in
> > > > > comments where you are having questions/problems). I cannot understand
> > > > > how exactly you are trying to "share data" and when you are trying to
> > > > > "use pContext". What you want to do is possible -- it is a matter of
> > > > > the right sequence of code, but I can't tell what your current
> > > > > sequence is.
> >
> > > > > //David
> > > > >http://w3-4u.blogspot.com
> > > > >http://blogs.msdn.com/David.Wang
> > > > > //- Hide quoted text -
> >
> > > > - Show quoted text -- Hide quoted text -
> >
> > - Show quoted text -
> 
>

now when i used your approach as follows:

in default func:

::CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE) ThreadProc2, pCtxt, 0, NULL);

then

static int count = 0;
static void ThreadProc2(CHttpServerContext* pCtxt)
{
	::Sleep(30000);
	char send[256];
	sprintf(send, "hello: %d :: %d\r\n", ++count, pCtxt->m_pECB->ConnID);
	DWORD sz = strlen(send);
	pCtxt->WriteClient(send, &sz);
	pCtxt->ServerSupportFunction(HSE_REQ_DONE_WITH_SESSION, NULL, NULL, NULL);
}

it gave me the same results, the third conn received the first conn's 
response !!

"Ibrahim Shahin" wrote:

> because as i mentioned b4 the delay will not come from any processing inside 
> my dll but the processing will accur in another process, so my threadpool 
> will act like a collection of threads waiting on a completion-port that have 
> multiple async WSARecv() calls initiated on it.
> 
> "David Wang" wrote:
> 
> > Ok, that's the part I don't understand. Why is some other thread
> > dispatching requests to ThreadProc. Because if it controls dispatching
> > requests, it also controls the strange "behavior" that you observe.
> > 
> > Usually, I expect dispatch of the ECB to the ThreadPool to happen
> > within HttpExtensionProc. The ThreadPool immediately finds an
> > available pool Thread (either threads are waiting on the ThreadPool's
> > "outstanding queue", or ThreadPool tracks available threads and
> > immediately dispatches). At the time of dispatch, ThreadPool hands the
> > ECB to the Thread's ThreadProc.
> > 
> > No shared data of any sort is needed to pass async data around.
> > 
> > 
> > //David
> > http://w3-4u.blogspot.com
> > http://blogs.msdn.com/David.Wang
> > //
> > 
> > 
> > 
> > On Jan 14, 4:29 pm, Ibrahim Shahin
> >  wrote:
> > > through the linked list, in my simulation, i have added a timestamp (request
> > > start) to each request and add a struct containing both of pCtxt and
> > > timestamp to the list, then threadproc get requests that have been idle for
> > > 30 sec.
> > >
> > >
> > >
> > > "David Wang" wrote:
> > > > How is each ECB being passed to ThreadProc for every request into
> > > > HttpExtensionProc?
> > >
> > > > //David
> > > >http://w3-4u.blogspot.com
> > > >http://blogs.msdn.com/David.Wang
> > > > //
> > >
> > > > On Jan 14, 3:41 pm, Ibrahim Shahin
> > > >  wrote:
> > > > > ////
> > >
> > > > > static count = 0;
> > > > > static LinkedList mLst;
> > >
> > > > > BOOL CMyExtension::GetExtensionVersion(HSE_VERSION_INFO* pVer)
> > > > > {
> > > > >         //start threads
> > >
> > > > > }
> > >
> > > > > DWORD CMyExtension::HttpExtensionProc(EXTENSION_CONTROL_BLOCK *pECB)
> > > > > {
> > > > >         DWORD  dwResult = CHttpServer::HttpExtensionProc(pECB);
> > > > >         if(dwResult == HSE_STATUS_SUCCESS)
> > > > >           return HSE_STATUS_PENDING;
> > > > >         else
> > > > >           return dwResult;
> > >
> > > > > }
> > >
> > > > > void CMyExtension::Default(CHttpServerContext* pCtxt)
> > > > > {
> > > > >         //
> > > > >         mLst.Add(pCtxt);
> > > > >         //
> > >
> > > > > }
> > >
> > > > > static void ThreadProc()
> > > > > {
> > > > >         //
> > > > >         //wait for finished tasks (in my test, i simulated the time to be fixed for
> > > > > about 30 sec)
> > > > >         //if task is finished
> > > > >         char data[256];
> > > > >         sprintf(data, "sending to no: %d - connID: %d\r\n", ++count,
> > > > > task.pCtxt->m_pECB->ConnID);
> > > > >         DWORD sz = strlen(data);
> > > > >         task.pCtxt->WriteClient(data, &sz); //write back response
> > > > >         task.pCtxt->ServerSupportFunction(HSE_REQ_DONE_WITH_SESSION, NULL, NULL,
> > > > > NULL);
> > > > >         mLst.Remove(task.pCtxt);
> > > > >         //
> > >
> > > > > }
> > >
> > > > > if i used a 3 instances of my client to be opened quicly after each other
> > > > > before the 30 sec elapsed
> > >
> > > > > the output will be:
> > >
> > > > > 1st:
> > >
> > > > > will pend on sock.recv() and will not receive anything
> > >
> > > > > 2nd:
> > >
> > > > > sending to no: 2 - connID: 11111011
> > >
> > > > > 3rd:
> > >
> > > > > sending to no: 1 - connID: 11111001
> > > > > //sending to no: 3 - connID: 11111001 //this will not be sent coz of
> > > > > DONE_WITH_SESSION of the 1st
> > >
> > > > > "David Wang" wrote:
> > > > > > On Jan 13, 3:07 pm, Ibrahim Shahin
> > > > > >  wrote:
> > > > > > > dear all,
> > >
> > > > > > >  i'm working on developing an extension for the purpose of some long-timed
> > > > > > > requests, so after writing the main blocks of the code using VC++6..0 + MFC
> > > > > > > that includes a separate thread pool & some shared datastructures with simple
> > > > > > > sync mechanism, my test is as follows:
> > >
> > > > > > > 1- return HSE_STATUS_PENDING to the server
> > >
> > > > > > > 2- pass pCtxt to my thread pool
> > >
> > > > > > > 3- threadpool will check periodically for active connections, and when a
> > > > > > > connection reaches a certain time (eg: 30 sec- 2 min) it uses writeclient()
> > > > > > > for sending reply then it call ServerSupportFunction() with
> > > > > > > HSE_REQ_DONE_WITH_SESSION and removes pCtxt from my active conn.(s)' list
> > >
> > > > > > > 4- the client that i used for testing do open multiple connections
> > > > > > > requesting ext.'s dll from the server, so i can detect number of simaltenious
> > > > > > > conn.(s)
> > >
> > > > > > > but i found something strange, the client can only have 2 simalt. conn..(s)
> > > > > > > active with iis at a time, and any new request come from the same ip, the iis
> > > > > > > reuse one of the 2 active conn.(s)' connID to be used with it, even i think
> > > > > > > it leaves all the sockets opening (old and new) but reuse connID which is
> > > > > > > used by writeclient(), so in my test, the last 2 conn.(s) recieved all the
> > > > > > > sent data to the opened connections.
> > >
> > > > > > > if this is a limitation of win xp iis, so how could this operate if the
> > > > > > > requests are coming from behind nat or proxy.
> > >
> > > > > > > another question is about async callbacks, if i used async writeclient() for
> > > > > > > example, can i access any shared data inside dll from it or i can use only
> > > > > > > pECB's included functions pointers (as callback is not running actually in my
> > > > > > > dll ??), seems no to me (accessing shared data failed) !!!, and how could i
> > > > > > > use the pContext arg of callback, should i pass the pCtxt first when i call
> > > > > > > ServerSupportFunction() with HSE_REQ_IO_COMPLETION as the last parameter.
> > >
> > > > > > >  thx,
> > >
> > > > > > > with regards
> > >
> > > > > > That two connection limit seems to come from your test client -- for
> > > > > > example, WinInet (what IE uses) has such a limit against a single
> > > > > > server.
> > >
> > > > > > However, IIS 5.1 on XP Pro does have a 10 connection limit, so it will
> > > > > > not be ideal for you to test your particular behavior even when you
> > > > > > unblock the test client.
> > >
> > > > > > The way you describe your testing of long async requests is strange.
> > > > > > All you need is a thread pool whose threadproc sleeps 30 sec to 2
> > > > > > minutes before using the ECB to WriteClient and DoneWithSession. There
> > > > > > is no need for threadpool to check for active connections. Makes me
> > > > > > wonder if you have a correctly written Threadpool.
> > >
> > > > > > Please show the code illustrating what you are talking about (put in
> > > > > > comments where you are having questions/problems). I cannot understand
> > > > > > how exactly you are trying to "share data" and when you are trying to
> > > > > > "use pContext". What you want to do is possible -- it is a matter of
> > > > > > the right sequence of code, but I can't tell what your current
> > > > > > sequence is.
> > >
> > > > > > //David
> > > > > >http://w3-4u.blogspot.com
> > > > > >http://blogs.msdn.com/David.Wang
> > > > > > //- Hide quoted text -
> > >
> > > > > - Show quoted text -- Hide quoted text -
> > >
> > > - Show quoted text -
> > 
> >

Where is pCtxt coming from -- is the variable on the stack or on the
heap -- and when does the Default func get invoked?

And you said your test client makes multiple requests -- are they over
different connections? Because multiple HTTP requests over the same
connection are supposed to be sequential, not simultaneous.

You've got this MFC ISAPI layer in the middle of everything. Get rid
of it; you're not using it and it is known to have "special" behavior
for ISAPI Extensions. For example, the Default function tries to parse
querystring for commands and can fail if none are given on the
request. Perhaps that is why connection #1 is not working.

I simply do not see what you claim with pure ISAPI and Win32 on XP
Pro. So, I am examining all the assumptions.

I want to make sure that:
1. Clients are making multiple requests over multiple connections
simultaneously (which simulates multiple independent users each making
some requests to your ISAPI)
2. On every request that reaches HttpExtensionProc its ECB is passed
off to a ThreadProc who waits for 30 seconds before using the ECB to
WriteClient() and then DONE_WITH_SESSION
3. The HttpExtensionProc returns HSE_STATUS_PENDING for every ECB that
is successfully passed off to a ThreadProc

I don't trust any special classes, etc -- just pure ISAPI can easily
do this setup.

Finally, using the value of ECB->ConnID as indication of unique
connection is incorrect. It is opaque data. IIS aggressively uses its
allocation cache, especially for situations like this, so it does not
surprise me to see it "re-used".

I'm guessing that you want to measure how simultaneous the request
handling can be -- given your asynchronous IO, it would be limited by
the number of threads simultaneously executing ThreadProc -- so I
suggest setting some global RequestCounter which increments for every
single request handled by HttpExtensionProc, is handed over along with
ECB to the ThreadProc, and the ThreadProc log the ID before the Sleep
and after the Sleep -- so that you can prove inside a log file th
multiple threads are doing work simultaneously.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//




On Jan 14, 5:58 pm, Ibrahim Shahin
 wrote:
> now when i used your approach as follows:
>
> in default func:
>
> ::CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE) ThreadProc2, pCtxt, 0, NULL);
>
> then
>
> static int count = 0;
> static void ThreadProc2(CHttpServerContext* pCtxt)
> {
>         ::Sleep(30000);
>         char send[256];
>         sprintf(send, "hello: %d :: %d\r\n", 流⺞, pCtxt->m_pECB->ConnID);
>         DWORD sz = strlen(send);
>         pCtxt->WriteClient(send, &sz);
>         pCtxt->ServerSupportFunction(HSE_REQ_DONE_WITH_SESSION, NULL, NULL, NULL);
>
> }
>
> it gave me the same results, the third conn received the first conn's
> response !!
>
>
>
> "Ibrahim Shahin" wrote:
> > because as i mentioned b4 the delay will not come from any processing inside
> > my dll but the processing will accur in another process, so my threadpool
> > will act like a collection of threads waiting on a completion-port that have
> > multiple async WSARecv() calls initiated on it.
>
> > "David Wang" wrote:
>
> > > Ok, that's the part I don't understand. Why is some other thread
> > > dispatching requests to ThreadProc. Because if it controls dispatching> > > requests, it also controls the strange "behavior" that you observe.
>
> > > Usually, I expect dispatch of the ECB to the ThreadPool to happen
> > > within HttpExtensionProc. The ThreadPool immediately finds an
> > > available pool Thread (either threads are waiting on the ThreadPool's
> > > "outstanding queue", or ThreadPool tracks available threads and
> > > immediately dispatches). At the time of dispatch, ThreadPool hands the> > > ECB to the Thread's ThreadProc.
>
> > > No shared data of any sort is needed to pass async data around.
>
> > > //David
> > >http://w3-4u.blogspot.com
> > >http://blogs.msdn.com/David.Wang
> > > //
>
> > > On Jan 14, 4:29 pm, Ibrahim Shahin
> > >  wrote:
> > > > through the linked list, in my simulation, i have added a timestamp (request
> > > > start) to each request and add a struct containing both of pCtxt and> > > > timestamp to the list, then threadproc get requests that have been idle for
> > > > 30 sec.
>
> > > > "David Wang" wrote:
> > > > > How is each ECB being passed to ThreadProc for every request into
> > > > > HttpExtensionProc?
>
> > > > > //David
> > > > >http://w3-4u.blogspot.com
> > > > >http://blogs.msdn.com/David.Wang
> > > > > //
>
> > > > > On Jan 14, 3:41 pm, Ibrahim Shahin
> > > > >  wrote:
> > > > > > ////
>
> > > > > > static count = 0;
> > > > > > static LinkedList mLst;
>
> > > > > > BOOL CMyExtension::GetExtensionVersion(HSE_VERSION_INFO* pVer)
> > > > > > {
> > > > > >         //start threads
>
> > > > > > }
>
> > > > > > DWORD CMyExtension::HttpExtensionProc(EXTENSION_CONTROL_BLOCK *pECB)
> > > > > > {
> > > > > >         DWORD  dwResult = CHttpServer::HttpExtensionProc(pECB);
> > > > > >         if(dwResult == HSE_STATUS_SUCCESS)
> > > > > >           return HSE_STATUS_PENDING;
> > > > > >         else
> > > > > >           return dwResult;
>
> > > > > > }
>
> > > > > > void CMyExtension::Default(CHttpServerContext* pCtxt)
> > > > > > {
> > > > > >         //
> > > > > >         mLst.Add(pCtxt);
> > > > > >         //
>
> > > > > > }
>
> > > > > > static void ThreadProc()
> > > > > > {
> > > > > >         //
> > > > > >         //wait for finished tasks (in my test, i simulated the time to be fixed for
> > > > > > about 30 sec)
> > > > > >         //if task is finished
> > > > > >         char data[256];
> > > > > >         sprintf(data, "sending to no: %d - connID: %d\r\n", 流⺞,
> > > > > > task.pCtxt->m_pECB->ConnID);
> > > > > >         DWORD sz = strlen(data);
> > > > > >         task.pCtxt->WriteClient(data, &sz); //write back response
> > > > > >         task.pCtxt->ServerSupportFunction(HSE_REQ_DONE_WITH_SESSION, NULL, NULL,
> > > > > > NULL);
> > > > > >         mLst.Remove(task.pCtxt);
> > > > > >         //
>
> > > > > > }
>
> > > > > > if i used a 3 instances of my client to be opened quicly after each other
> > > > > > before the 30 sec elapsed
>
> > > > > > the output will be:
>
> > > > > > 1st:
>
> > > > > > will pend on sock.recv() and will not receive anything
>
> > > > > > 2nd:
>
> > > > > > sending to no: 2 - connID: 11111011
>
> > > > > > 3rd:
>
> > > > > > sending to no: 1 - connID: 11111001
> > > > > > //sending to no: 3 - connID: 11111001 //this will not be sent coz of
> > > > > > DONE_WITH_SESSION of the 1st
>
> > > > > > "David Wang" wrote:
> > > > > > > On Jan 13, 3:07 pm, Ibrahim Shahin
> > > > > > >  wrote:
> > > > > > > > dear all,
>
> > > > > > > >  i'm working on developing an extension for the purpose of some long-timed
> > > > > > > > requests, so after writing the main blocks of the code using VC..0  MFC
> > > > > > > > that includes a separate thread pool & some shared datastructures with simple
> > > > > > > > sync mechanism, my test is as follows:
>
> > > > > > > > 1- return HSE_STATUS_PENDING to the server
>
> > > > > > > > 2- pass pCtxt to my thread pool
>
> > > > > > > > 3- threadpool will check periodically for active connections, and when a
> > > > > > > > connection reaches a certain time (eg: 30 sec- 2 min) it uses writeclient()
> > > > > > > > for sending reply then it call ServerSupportFunction() with
> > > > > > > > HSE_REQ_DONE_WITH_SESSION and removes pCtxt from my active conn.(s)' list
>
> > > > > > > > 4- the client that i used for testing do open multiple connections
> > > > > > > > requesting ext.'s dll from the server, so i can detect number of simaltenious
> > > > > > > > conn.(s)
>
> > > > > > > > but i found something strange, the client can only have 2 simalt. conn..(s)
> > > > > > > > active with iis at a time, and any new request come from the same ip, the iis
> > > > > > > > reuse one of the 2 active conn.(s)' connID to be used with it, even i think
> > > > > > > > it leaves all the sockets opening (old and new) but reuse connID which is
> > > > > > > > used by writeclient(), so in my test, the last 2 conn.(s) recieved all the
> > > > > > > > sent data to the opened connections.
>
> > > > > > > > if this is a limitation of win xp iis, so how could this operate if the
> > > > > > > > requests are coming from behind nat or proxy.
>
> > > > > > > > another question is about async callbacks, if i used async writeclient() for
> > > > > > > > example, can i access any shared data inside dll from it or i can use only
> > > > > > > > pECB's included functions pointers (as callback is not running actually in my
> > > > > > > > dll ??), seems no to me (accessing shared data failed) !!!, and how could i
> > > > > > > > use the pContext arg of callback, should i pass the pCtxt first when i call
> > > > > > > > ServerSupportFunction() with HSE_REQ_IO_COMPLETION as the last parameter.
>
> > > > > > > >  thx,
>
> > > > > > > > with regards
>
> > > > > > > That two connection limit seems to come from your test client -- for
> > > > > > > example, WinInet (what IE uses) has such a limit against a single
> > > > > > > server.
>
> > > > > > > However, IIS 5.1 on XP Pro does have a 10 connection limit, so it will
> > > > > > > not be ideal for you to test your particular behavior even when you
> > > > > > > unblock the test client.
>
> > > > > > > The way you describe your testing of long async requests is strange.
> > > > > > > All you need is a thread pool whose threadproc sleeps 30 sec to 2
> > > > > > > minutes before using the ECB to WriteClient and DoneWithSession. There
> > > > > > > is no need for threadpool to check for active connections. Makes me
> > > > > > > wonder if you have a correctly written Threadpool.
>
> > > > > > > Please show the code illustrating what you are talking about (put in
> > > > > > > comments where you are having questions/problems). I cannot understand
> > > > > > > how exactly you are trying to "share data" and when you are trying to
> > > > > > > "use pContext". What you want to do is possible -- it is a matter of
> > > > > > > the right sequence of code, but I can't tell what your current> > > > > > > sequence is.
>
> > > > > > > //David
> > > > > > >http://w3-4u.blogspot.com
> > > > > > >http://blogs.msdn.com/David.Wang
> > > > > > > //- Hide quoted text -
>
> > > > > > - Show quoted text -- Hide quoted text -
>
> > > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

about the client, it's do simult. async. connections not sequential.
i'll rewrite it in pure ISAPI and notify you with the results.

"David Wang" wrote:

> Where is pCtxt coming from -- is the variable on the stack or on the
> heap -- and when does the Default func get invoked?
> 
> And you said your test client makes multiple requests -- are they over
> different connections? Because multiple HTTP requests over the same
> connection are supposed to be sequential, not simultaneous.
> 
> You've got this MFC ISAPI layer in the middle of everything. Get rid
> of it; you're not using it and it is known to have "special" behavior
> for ISAPI Extensions. For example, the Default function tries to parse
> querystring for commands and can fail if none are given on the
> request. Perhaps that is why connection #1 is not working.
> 
> I simply do not see what you claim with pure ISAPI and Win32 on XP
> Pro. So, I am examining all the assumptions.
> 
> I want to make sure that:
> 1. Clients are making multiple requests over multiple connections
> simultaneously (which simulates multiple independent users each making
> some requests to your ISAPI)
> 2. On every request that reaches HttpExtensionProc its ECB is passed
> off to a ThreadProc who waits for 30 seconds before using the ECB to
> WriteClient() and then DONE_WITH_SESSION
> 3. The HttpExtensionProc returns HSE_STATUS_PENDING for every ECB that
> is successfully passed off to a ThreadProc
> 
> I don't trust any special classes, etc -- just pure ISAPI can easily
> do this setup.
> 
> Finally, using the value of ECB->ConnID as indication of unique
> connection is incorrect. It is opaque data. IIS aggressively uses its
> allocation cache, especially for situations like this, so it does not
> surprise me to see it "re-used".
> 
> I'm guessing that you want to measure how simultaneous the request
> handling can be -- given your asynchronous IO, it would be limited by
> the number of threads simultaneously executing ThreadProc -- so I
> suggest setting some global RequestCounter which increments for every
> single request handled by HttpExtensionProc, is handed over along with
> ECB to the ThreadProc, and the ThreadProc log the ID before the Sleep
> and after the Sleep -- so that you can prove inside a log file th
> multiple threads are doing work simultaneously.
> 
> 
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
> 
> 
> 
> 
> On Jan 14, 5:58 pm, Ibrahim Shahin
>  wrote:
> > now when i used your approach as follows:
> >
> > in default func:
> >
> > ::CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE) ThreadProc2, pCtxt, 0, NULL);
> >
> > then
> >
> > static int count = 0;
> > static void ThreadProc2(CHttpServerContext* pCtxt)
> > {
> >         ::Sleep(30000);
> >         char send[256];
> >         sprintf(send, "hello: %d :: %d\r\n", ++count, pCtxt->m_pECB->ConnID);
> >         DWORD sz = strlen(send);
> >         pCtxt->WriteClient(send, &sz);
> >         pCtxt->ServerSupportFunction(HSE_REQ_DONE_WITH_SESSION, NULL, NULL, NULL);
> >
> > }
> >
> > it gave me the same results, the third conn received the first conn's
> > response !!
> >
> >
> >
> > "Ibrahim Shahin" wrote:
> > > because as i mentioned b4 the delay will not come from any processing inside
> > > my dll but the processing will accur in another process, so my threadpool
> > > will act like a collection of threads waiting on a completion-port that have
> > > multiple async WSARecv() calls initiated on it.
> >
> > > "David Wang" wrote:
> >
> > > > Ok, that's the part I don't understand. Why is some other thread
> > > > dispatching requests to ThreadProc. Because if it controls dispatching
> > > > requests, it also controls the strange "behavior" that you observe.
> >
> > > > Usually, I expect dispatch of the ECB to the ThreadPool to happen
> > > > within HttpExtensionProc. The ThreadPool immediately finds an
> > > > available pool Thread (either threads are waiting on the ThreadPool's
> > > > "outstanding queue", or ThreadPool tracks available threads and
> > > > immediately dispatches). At the time of dispatch, ThreadPool hands the
> > > > ECB to the Thread's ThreadProc.
> >
> > > > No shared data of any sort is needed to pass async data around.
> >
> > > > //David
> > > >http://w3-4u.blogspot.com
> > > >http://blogs.msdn.com/David.Wang
> > > > //
> >
> > > > On Jan 14, 4:29 pm, Ibrahim Shahin
> > > >  wrote:
> > > > > through the linked list, in my simulation, i have added a timestamp (request
> > > > > start) to each request and add a struct containing both of pCtxt and
> > > > > timestamp to the list, then threadproc get requests that have been idle for
> > > > > 30 sec.
> >
> > > > > "David Wang" wrote:
> > > > > > How is each ECB being passed to ThreadProc for every request into
> > > > > > HttpExtensionProc?
> >
> > > > > > //David
> > > > > >http://w3-4u.blogspot.com
> > > > > >http://blogs.msdn.com/David.Wang
> > > > > > //
> >
> > > > > > On Jan 14, 3:41 pm, Ibrahim Shahin
> > > > > >  wrote:
> > > > > > > ////
> >
> > > > > > > static count = 0;
> > > > > > > static LinkedList mLst;
> >
> > > > > > > BOOL CMyExtension::GetExtensionVersion(HSE_VERSION_INFO* pVer)
> > > > > > > {
> > > > > > >         //start threads
> >
> > > > > > > }
> >
> > > > > > > DWORD CMyExtension::HttpExtensionProc(EXTENSION_CONTROL_BLOCK *pECB)
> > > > > > > {
> > > > > > >         DWORD  dwResult = CHttpServer::HttpExtensionProc(pECB);
> > > > > > >         if(dwResult == HSE_STATUS_SUCCESS)
> > > > > > >           return HSE_STATUS_PENDING;
> > > > > > >         else
> > > > > > >           return dwResult;
> >
> > > > > > > }
> >
> > > > > > > void CMyExtension::Default(CHttpServerContext* pCtxt)
> > > > > > > {
> > > > > > >         //
> > > > > > >         mLst.Add(pCtxt);
> > > > > > >         //
> >
> > > > > > > }
> >
> > > > > > > static void ThreadProc()
> > > > > > > {
> > > > > > >         //
> > > > > > >         //wait for finished tasks (in my test, i simulated the time to be fixed for
> > > > > > > about 30 sec)
> > > > > > >         //if task is finished
> > > > > > >         char data[256];
> > > > > > >         sprintf(data, "sending to no: %d - connID: %d\r\n", ++count,
> > > > > > > task.pCtxt->m_pECB->ConnID);
> > > > > > >         DWORD sz = strlen(data);
> > > > > > >         task.pCtxt->WriteClient(data, &sz); //write back response
> > > > > > >         task.pCtxt->ServerSupportFunction(HSE_REQ_DONE_WITH_SESSION, NULL, NULL,
> > > > > > > NULL);
> > > > > > >         mLst.Remove(task.pCtxt);
> > > > > > >         //
> >
> > > > > > > }
> >
> > > > > > > if i used a 3 instances of my client to be opened quicly after each other
> > > > > > > before the 30 sec elapsed
> >
> > > > > > > the output will be:
> >
> > > > > > > 1st:
> >
> > > > > > > will pend on sock.recv() and will not receive anything
> >
> > > > > > > 2nd:
> >
> > > > > > > sending to no: 2 - connID: 11111011
> >
> > > > > > > 3rd:
> >
> > > > > > > sending to no: 1 - connID: 11111001
> > > > > > > //sending to no: 3 - connID: 11111001 //this will not be sent coz of
> > > > > > > DONE_WITH_SESSION of the 1st
> >
> > > > > > > "David Wang" wrote:
> > > > > > > > On Jan 13, 3:07 pm, Ibrahim Shahin
> > > > > > > >  wrote:
> > > > > > > > > dear all,
> >
> > > > > > > > >  i'm working on developing an extension for the purpose of some long-timed
> > > > > > > > > requests, so after writing the main blocks of the code using VC++6..0 + MFC
> > > > > > > > > that includes a separate thread pool & some shared datastructures with simple
> > > > > > > > > sync mechanism, my test is as follows:
> >
> > > > > > > > > 1- return HSE_STATUS_PENDING to the server
> >
> > > > > > > > > 2- pass pCtxt to my thread pool
> >
> > > > > > > > > 3- threadpool will check periodically for active connections, and when a
> > > > > > > > > connection reaches a certain time (eg: 30 sec- 2 min) it uses writeclient()
> > > > > > > > > for sending reply then it call ServerSupportFunction() with
> > > > > > > > > HSE_REQ_DONE_WITH_SESSION and removes pCtxt from my active conn.(s)' list
> >
> > > > > > > > > 4- the client that i used for testing do open multiple connections
> > > > > > > > > requesting ext.'s dll from the server, so i can detect number of simaltenious
> > > > > > > > > conn.(s)
> >
> > > > > > > > > but i found something strange, the client can only have 2 simalt. conn..(s)
> > > > > > > > > active with iis at a time, and any new request come from the same ip, the iis
> > > > > > > > > reuse one of the 2 active conn.(s)' connID to be used with it, even i think
> > > > > > > > > it leaves all the sockets opening (old and new) but reuse connID which is
> > > > > > > > > used by writeclient(), so in my test, the last 2 conn.(s) recieved all the
> > > > > > > > > sent data to the opened connections.
> >
> > > > > > > > > if this is a limitation of win xp iis, so how could this operate if the
> > > > > > > > > requests are coming from behind nat or proxy.
> >
> > > > > > > > > another question is about async callbacks, if i used async writeclient() for
> > > > > > > > > example, can i access any shared data inside dll from it or i can use only
> > > > > > > > > pECB's included functions pointers (as callback is not running actually in my
> > > > > > > > > dll ??), seems no to me (accessing shared data failed) !!!, and how could i
> > > > > > > > > use the pContext arg of callback, should i pass the pCtxt first when i call
> > > > > > > > > ServerSupportFunction() with HSE_REQ_IO_COMPLETION as the last parameter.
> >
> > > > > > > > >  thx,
> >
> > > > > > > > > with regards
> >
> > > > > > > > That two connection limit seems to come from your test client -- for
> > > > > > > > example, WinInet (what IE uses) has such a limit against a single
> > > > > > > > server.
> >
> > > > > > > > However, IIS 5.1 on XP Pro does have a 10 connection limit, so it will
> > > > > > > > not be ideal for you to test your particular behavi