I wanted to find out for sure if the INGROUP function in 4.02 was less network intensive than in version 3.63. These results are by no means completely conclusive but they are interesting.
Packets Captured					

KiXtart
Version Number of Ingroup calls (diff groups)
1 2 3 4 5 6 7

4.02	140	137	137	129	125	121	134
3.63 177 182 170 161 157 157 165


4.02 121 125 121 133 121 122 122
3.63 175 157 158 162 157 157 157

							
Loop 100 iterations of checking the same groups as above
4.02 135 121 137 133 136 121 121
3.63 176 173 157 169 158 157 157


But this seems to show that once a single INGROUP function is called certain data must be cached. As a general rule it appears that for this test version 4.02 required ~30 less packets (20%) for executing the functionality as that required for version 3.63.

I have queried Ruud:
quote:
I have made some statements internally as well on the KiXtart.org
related to the improved performance and lack of network traffic because
of my assumption the checking the security token would not cause network
traffic. After getting the correct facts, I would like to correct these
posts.

Below is some additional insight from Ruud:
quote:
accessing the local security token indeed does not involve any network
traffic. However, KiXtart needs to translate the SIDs in the token to
groupnames (*), and that does require queries to the domain controller.
This is why I introduced the tokencache, which saves a bundle of frames
on subsequent runs of KIX32 (and even makes it possible to use InGroup
when you are offline). However, even with the cache, you will still see
communication with the domain controller to retrieve things like the
full name, password age, etc. Today, most of these things are retrieved
as a single 'bundle' (ie: if you use @FULLNAME, I retrieve the password
age at the same time). There are pros and cons to this, and this may
change in the future.

Let me know if this clarifies things.

Cheers,

--Ruud

(*): note that I have chosen to xlate all SIDs of the user to
groupnames, and not the other way around: xlating the groupnames in a
script to SIDs. Both methods can work, but the latter would involve
network traffic every time InGroup is called, and also would become very
inefficient if a script has many InGroup commands on different groups.

This is the last test script used:
code:
break on
$i=1
while $i <= 100

if ingroup("amp01\nt_techies")
endif
if ingroup("amp01\InternetAllowed")
endif
if ingroup("amp01\H")
endif
if ingroup("amp01\nt_techies")
endif
if ingroup("amp01\Badnt_techies")
endif
if ingroup("amp01\Domain Users")
endif
if ingroup("amp01\InternetDenied")
endif

$i = $i+1
loop

The only communications that should have occurred should be related to the INGROUP function unless as Ruud eludes to above that even for a group call the user data is also returned. Maybe Ruud will provide additional data in the future.

[ 01 May 2002, 20:19: Message edited by: Howard Bullock ]
_________________________
Home page: http://www.kixhelp.com/hb/