Alternatives

> I think the best we can do is try to get people with knowledge of the
> alternatives to post information and educate us. I think that would be
> very valuable, and of course it would get included in the KB.

I've become a pretty vocal hater of COM, COM+ and DCOM.

One technique that has worked exceptionally well for me is using straight
TCPIP.

I bought the DART package because it seemed the most complete of all those I
looked at. There are some very good TCPIP pacakages out there though.

The WinSock control won't work because of issues using it in a multithreaded
ActiveX EXE (and you have to code your server as a multithreaded EXE to be
much of a multi user capable server).!

I marshal disconnected recordsets directly into a property bag and send the
bag contents VIA TCPIP. I could switch to XML at any time and probably roll
my own SOAP layer too, if I really need it.

The beauty of it all is, I haven't had a single "version compatibility"
problem, or deployment issue since switching. I manage all the security, so
I don't have to mess with DCOM stuff and the registry, and my server doesn't
even have to belong to the domain. It just has to be reachable through
TCPIP.


Anyway, it's worked well for me. I wouldn't thing of bothering with MTS, or
COM+ now...

[Pierre G. Boutquin]

<Darin> wrote in message news:3a9dd558@news.devx.com...
> I've become a pretty vocal hater of COM, COM+ and DCOM.
>
> One technique that has worked exceptionally well for me is using straight
> TCPIP.

Glad this works for you.

It's a tradeoff though, e.g. how many concurrent user connections can you
support with your approach?

I need to design a system that can support 50,000 concurrent connections, so
I'm a bit more constrained with my architectural choices.

<Pierre/>

[Joe \Nuke Me Xemu\ Foster]

"Pierre G. Boutquin" <boutquin@home.com> wrote in message <news:3aa6eb07@news.devx.com>...

> <Darin> wrote in message news:3a9dd558@news.devx.com...
> > I've become a pretty vocal hater of COM, COM+ and DCOM.
> >
> > One technique that has worked exceptionally well for me is using straight
> > TCPIP.
>
> Glad this works for you.
>
> It's a tradeoff though, e.g. how many concurrent user connections can you
> support with your approach?
>
> I need to design a system that can support 50,000 concurrent connections, so
> I'm a bit more constrained with my architectural choices.

What would if naked TCP cannot? Clustered servers, thread pools, and raw UDP?

--
Joe Foster <mailto:jfoster@ricochet.net> Space Cooties! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Pierre G. Boutquin]

"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
news:3aa83c10@news.devx.com...
> What would if naked TCP cannot? Clustered servers, thread pools, and raw
UDP?

True, but there's a lot of plumbing to build. COM+ (or J2EE but that's
another discussion) gets you to market faster.

<Pierre/>

[Joe \Nuke Me Xemu\ Foster]

"Pierre G. Boutquin" <boutquin@home.com> wrote in message <news:3ab04311@news.devx.com>...

> "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
> news:3aa83c10@news.devx.com...
> > What would if naked TCP cannot? Clustered servers, thread pools, and raw
> UDP?
>
> True, but there's a lot of plumbing to build. COM+ (or J2EE but that's
> another discussion) gets you to market faster.

I've prototyped using DCOM and Remote Automation before it and replaced
with TCP as needed, often with very little impact on the client code.
Instead of creating a remote object, they create a local object which
wraps the communication, a matter of adding a new class module and a
one-line code change elsewhere.

--
Joe Foster <mailto:jfoster@ricochet.net> Got Thetans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

"Pierre G. Boutquin" <boutquin@home.com> wrote in message
news:3ab04311@news.devx.com...
> "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
> news:3aa83c10@news.devx.com...
> > What would if naked TCP cannot? Clustered servers, thread pools, and raw
> UDP?
>
> True, but there's a lot of plumbing to build. COM+ (or J2EE but that's
> another discussion) gets you to market faster.

Depends on the deployment. If the app is being deployed over the internet,
DCOM, COM+, MSMQ, etc all tend to fall down. Getting DCOM going over the
internet is not for the faint of heart. TCPIP is far simpler.


BTW, when you say 50000 concurrent connections. do you really MEAN 50000
open connections to a single machine simultaneously, or simply 50000 users
who all "appear" to be connected. There's a big difference.

Even in a relatively large installation (100-200 users), I've noticed that
at any one time, only 3-10 are actually simultaneously performing an
operation against the server.

The biggest trick in coding things like this is getting VB to multithread
properly so no thread blocks on any of the others. It's completely doable,
you just have to be cognizant of what VB's doing...

[Joe \Nuke Me Xemu\ Foster]

<Darin> wrote in message <news:3ab35e53@news.devx.com>...

> Even in a relatively large installation (100-200 users), I've noticed that
> at any one time, only 3-10 are actually simultaneously performing an
> operation against the server.

You too, eh? A little monitoring shows that I can often get away with
MSDE, at least until MS modified the EULA to "per seat" from "per
connection". After all, a pool of five bank tellers can handle a lot
of customers!

> The biggest trick in coding things like this is getting VB to multithread
> properly so no thread blocks on any of the others. It's completely doable,
> you just have to be cognizant of what VB's doing...

Is there a FAQ or something to show everyone who claims apartment model
is hopelessly crippled? However, it seems a waste to mutex an object
when most threads are merely reading it. .NOT's ReaderWriterLock would
be a cool thing to backport, if only...

--
Joe Foster <mailto:jfoster@ricochet.net> DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

> .NOT's ReaderWriterLock would
> be a cool thing to backport, if only...

There's quite a few things in .NET I wish they'd backport, but then you'd
have VB7 and not visual fred<g>

[Joe \Nuke Me Xemu\ Foster]

<Darin> wrote in message <news:3ab607a4@news.devx.com>...

> > .NOT's ReaderWriterLock would
> > be a cool thing to backport, if only...
>
> There's quite a few things in .NET I wish they'd backport, but then you'd
> have VB7 and not visual fred<g>

Are you sure you want MS to backport them? Have you seen MS PSS'
backports of VB6' "new" string functions? They're so bad it had
to be a conspiracy to force everyone to VB6, even if VB5 would
otherwise have continued to do the job just fine!

http://support.microsoft.com/support.../Q188/0/07.ASP

--
Joe Foster <mailto:jfoster@ricochet.net> "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!