T
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
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