I was getting the impression it was time I built this myself rather than
retrofitting an example.
Which leads on to my next question. I'm also getting a very strong
impression that multithreaded listeners are best implemented in C#.
I'm particularly focused on stability, scalability and performance
lock... i remember that i had a horrible problem with deadlocks and
asynchronous sockets. It was a nightmare to find out what was happening! I
don't remember the behavior, though. Are you doing synchronization?
- Original Message -
From: "Garry Barclay" <[EMAIL PROTECTED]>
To: <[EMAIL PRO
Our server only has one appdomain, and it works great. Another thing you really need
to be careful about is the whole callback thing. Assume that your callbacks will be
coming back on multiple IO threads. This will definitely be the case when running on
a multi-processor box (or hyperthreaded
> I saw one of these in the help, but I couldn't figure out how and where to
> plug it in.
> Can you explain how your would implement this?
This is one way of doing it - change it as needed for your situation. You'll
want to break this up into separate functions, threads, etc.
Dim tcpListener As
Thanks,
I saw one of these in the help, but I couldn't figure out how and where to
plug it in.
Can you explain how your would implement this?
- Original Message -
From: "Jeff Paulsen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 23, 2004 4:42 AM
Subject: Re: [ADVANCED-DO
Are you using application domains != from main application domain to host
and execute System.Net.Sockets? If so, did you try to do the same in the
main application domain?
Manuel
P.S.: good luck!
- Original Message -
From: "Garry Barclay" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent
This problem is happening on a fresh installation of .Net Server 2003.
There's no virus checker running.
There's no explicit pinning in our code - the framework Socket
implementation pins the buffers before issuing the IOs to winsock.
Our application is a fairly big one, with multiple appdomains
> but then I get property client() is not accessible in this context because
> it's protected
The quick and dirty solution to this might be to make a subclass of
tcpclient that doesn't have its socket property marked Protected, thus:
Class ExposedSocketTcpClient
Inherits TcpClient
> Dim ClientSocket As Socket = Me.Client
> which should(?) be
> Dim ClientSocket As Socket = Myclient.Client
> but then I get property client() is not accessible in this
> context because it's protected
>
> Can you tell me how to get the socket in this context, or do
> I need to pick it up from t
Hmm,
If you never remove the entries in the hashtable
(what you seem to do with the dataTables)
you can simplify it like...
Hashtable ht = new Hashtable();
Hashtable locks = new Hashtable();
private object GetLockObject( HashKey key)
{
object singleLock = locks[key];
if ( singleLock == null
Hi James,
I thought about that, but wanted to keep things simple ;)
Lets try this one, (very experimental)...
Hashtable ht = new Hashtable();
Hashtable locks = Hashtable.Synchronized( new Hashtable());
private object GetLockObject( HashKey key)
{
Object object = locks[key];
if ( object == n
Hi Ryan,
This looks better than my original suggestion - however, this doesn't
allow for different combinations of parameters to be called in parallel:
this database call could take a few seconds, and the results depending
on the parameters will be different. Perhaps I need a hashtable of lock
ob
Hi James,
the synchronized Hashtable only syncs the hashTable
to sync also the db access, try this one...
Hashtable ht = new Hashtable();
public DataTable GetList( int a, int b, int c)
{
// lookup the dataTable
DataTable dt = (DataTable)ht[key];
if ( dt == null)
{
// since our last
13 matches
Mail list logo
