Want multiple copies of a DLL to run...

24 Nov 2006 5:25 PM

tony obrien

Hi,

I have written a VB.Net Class Library to handle TCP message traffic between
a client and a server. (i.e. I have exposed Props/Methods to a caller and
handle the gory details regarding encryption and msg handling back and fro
to the server in the DLL.)

For a single client, this all works swell.

Now I am endeavoring to create a LOAD TESTER which is nothing more than a
means to generate LOTS of meaningful traffic to my server.

So, I have tried to write a simple routine which creates n-threads each
trying to create its OWN COPY of the DLL i.e. each thread's start routine
has ...

dim myDLL as theDLLCls
myDLL = New theDLLCls

But I get all kinds of weirdy errors in the DLL's handlers.

Everything I've read so far is all about using SyncLock around the areas
using variables in the DLL, etc etc etc... but thats NOT what I want.. .in
fact the problem is that my DLL is essesntially NOT STATELESS... it MUST
remember particular things about ITS connection which WILL BE DIFFERENT in
all other connections. So SynckLocking isn;t corrrect because I DON'T WANT
ANOTHER thread mucking with the data.

So, how does one go about ensuring that fresh, unique copy of the DLL class
gets used in each thread that is spawned??

BTW I have ALL variables in the class as PRIVATE, but of course there are
"public" properties and ethods to allow the caller to get to the member
(private) variables.

Any and all ideas are most welcome.

regards,
tob

24 Nov 2006 5:35 PM

Robinson

> BTW I have ALL variables in the class as PRIVATE, but of course there are
> "public" properties and ethods to allow the caller to get to the member
> (private) variables.
>
> Any and all ideas are most welcome.
>

Why don't you wrap all of the properties (private and public) into a "State"
class, passing a new instance as an argument to the DLL for each thread you
have? Whenever you call a method on the DLL, you pass the state instance
for whichever thread you are making the call on behalf of.

24 Nov 2006 5:47 PM

tony obrien

Show quote Hide quote

"Robinson" <toomuchspamhaspassed@myinboxtoomuchtoooften.com> wrote in
news:ek7ag8$p78$1$8302bc10@news.demon.co.uk:

>
>> BTW I have ALL variables in the class as PRIVATE, but of course there
>> are "public" properties and ethods to allow the caller to get to the
>> member (private) variables.
>>
>> Any and all ideas are most welcome.
>>
>
> Why don't you wrap all of the properties (private and public) into a
> "State" class, passing a new instance as an argument to the DLL for
> each thread you have? Whenever you call a method on the DLL, you pass
> the state instance for whichever thread you are making the call on
> behalf of.
>
>
>
>
>
>
>
>

Hi....

I appreciate your suggestion but your asking me to "lug around" a ton of
TCP, and message states, and other stuff that the DLL was meant to handle
all by itself.

Isn't there a way to simply make sure that each NEW of the DLL is really
NEW?

regards,
tob