Can Classic ASP talk to C/C++?

[tanya.wang]

I have a system written in classic asp and a lot of Javascript. Due to
its performance and security issue, we decided to re-write this big
module. I heard that C/C++ has a better support in performance and
security (relatively) but here comes my questions:

1. Can ASP talk to C/C++? Because from my experience I use C/C++
mainly for application console.

2. If I want to exclude most of the Javascript and use other
programming language instead, can ASP.NET do it? Is there any
compatibility issue between Classic ASP/ASP.NET/Javascript?

Thank you for reading this.

 

[Anthony Jones]

I have a system written in classic asp and a lot of Javascript. Due to
its performance and security issue, we decided to re-write this big
module. I heard that C/C++ has a better support in performance and
security (relatively) but here comes my questions:

1. Can ASP talk to C/C++? Because from my experience I use C/C++
mainly for application console.

Through a COM interface yes. If you are truely are comfortable with C++
then its viable but only if you're a seasoned C++ developer. Otherwise
avoid this.

2. If I want to exclude most of the Javascript and use other
programming language instead, can ASP.NET do it? Is there any
compatibility issue between Classic ASP/ASP.NET/Javascript?

ASP and ASP.NET are very different things whilst its possible to coexist ASP
with ASP.NET the are significant hurdles to overcome when trying to port a
portion of an existing ASP app to ASP.NET. You could consider a complete
re-write to ASP.NET.

However possibly you are thinking of creating components to protect your IP,
..NET isn't great at that but is better then having all your code in open
script. You can do this with COM Interop layer to allo ASP code you access
..NET built components.

Whats the nature of your performance problems?

 

[Bob Barrows [MVP]]

I have a system written in classic asp and a lot of Javascript. Due to
its performance and security issue, we decided to re-write this big
module. I heard that C/C++ has a better support in performance and
security (relatively) but here comes my questions:

If, by "javascript", you mean "client-side code", then switching to a
non-script language in client-side code will mean forcing your users to
install extra software on their machines and disable security features
designed to prevent the execution of such code built into their browsers in
order to use your application. This is worrisome because:
1. unless you are in a LAN/WAN environment, you cannot force the users to do
so, so you will be limiting your application's audience - this may not be
worrisome to you
2. deploying software to large numbers of machines is a PITA - just ask any
IT department technician. Inevitably, there will be machines out there on
which your software just will not run due to
compatibility,/security/whatever issues

1. Can ASP talk to C/C++? Because from my experience I use C/C++
mainly for application console.

ASP is server-side technology. All it does is generate html to be sent to
the client. Once it is at the client, the browser is the limiting factor. So
if your performance bottleneck is in the client-side portion, ASP is
irrelevant to this problem. Have you identified where the bottleneck is? Is
your server-side code taking too long to generate the html to be sent to
your client? If so, using a component to run compiled code MIGHT help. There
are many reasons for bad performance that have nothing to do with the
language being used in the server-side code:
a. Insufficient network bandwidth
b. Insufficient server hardware
c. If a database is involved:
-insufficient database server hardware
-poorly designed database
-poorly written sql
-requesting too much data from the database

To paraphrase something the respected author Bill Vaughn has been known to
say: C++ waits just as fast as vbscript.

Before you take the step to rewrite code, you MUST identify the bottlenecks.

As for ASP "talking to" C.C++, Anthony already provided the answer: COM, the
use of which, by the way, carries its own performance impact. It is not
trivial to marshal data between processes, which is what has to happen when
using COM.

2. If I want to exclude most of the Javascript and use other
programming language instead, can ASP.NET do it?

Again, it depends on what you mean by "Javascript". Are you talking about
using javascript in server-side code? Or are you using the word the way many
people incorrectly use it. as a synonym for "client-side code"? Just like
ASP, ASP.Net is server-side technology. All it does is generate html to be
sent to the client. It has nothing to do with the code running on the client
browser, except insofar as generating the client-side code to be run there.
The code that runs in a browser is limited by the browser. If the browser is
configured to allow third-party software to run, then it will

Is there any
compatibility issue between Classic ASP/ASP.NET/Javascript?

Again, Anthony handled this, except for mentioning that ASP and ASP.Net will
not share session and application variables, so you will need to implement a
way to allow them to share information, usually via a database.

 

[tanya.wang]

Thank you Anthony and Bob, I appreciate your opinion.

Let me elaborate more about my previous questions. The system that I
was asking is more like an instant note sending system only available
to our website members. The core is written in ASP/Javascript and it
could be included in any of our webpages when it's required for the
development. The security issue is because 50% of it was written in
Javascript, and it's visible when one choose to view source in the
browser, some people begin putting some malicious codes inside the
subject/content and thereby attempting to hack our system. Since our
users are all over the Internet, it is probably not feasible to force
them install software if they would like to retrieve/send notes
online.

Yes, as you mentioned the Javascript is the client-side code. Since
it's client side, it implies the module may not function properly if
one turns off its Javascript support, such as using Firefox as the
default. We have received so many e-mails asking how come they cannot
use the note system, and 99.9% are due to Firefox. This is one of the
reasons that we would like to revise it. But in that case, a vbscript
may not be a good substitute since it's only supported by IE. A Server-
side technique is probably a better solution to this problem.

You guys both asked about the performance bottlenecks. It happened
when a user tried to send anyone a note, the lock block number in SQL
Server would go extremely high at the time that it was being send.
(approx. three times than usual) I have checked with our IT guy and he
said our bandwidth and DB hardware are both good to go. I am not sure
which exact point(s) results in these terrible spikes but I can tell
you we called a stored procedure that inserts a row for the content in
the table. Period. How could such a simple command result in a
tremendously poor performance?


So, sounds like I have to choose COM isn't it? Unfortunately I am not
a very professional C++ writer since I only touched it when at school.
But if this is the only one solution I guess there's no room for me to
say I am not familiar....

 

[Bob Barrows [MVP]]

Thank you Anthony and Bob, I appreciate your opinion.

Let me elaborate more about my previous questions. The system that I
was asking is more like an instant note sending system only available
to our website members. The core is written in ASP/Javascript and it
could be included in any of our webpages when it's required for the
development. The security issue is because 50% of it was written in
Javascript, and it's visible when one choose to view source in the
browser, some people begin putting some malicious codes inside the
subject/content and thereby attempting to hack our system.

This sounds as if you are using dynamic sql to handle he user input. As you
are finding out this is a bad idea. You need to implement a two-phase
approach:
1. Validate all user input in server-side code. Do not depend on client-side
validation. If possible, identify malicious input and kick the maliciouls
users out of the system
2. Use parameters instead of dynamic sql

Here are some links about sql injection

Since our
users are all over the Internet, it is probably not feasible to force
them install software if they would like to retrieve/send notes
online.

Yes, as you mentioned the Javascript is the client-side code. Since
it's client side, it implies the module may not function properly if
one turns off its Javascript support, such as using Firefox as the
default. We have received so many e-mails asking how come they cannot
use the note system, and 99.9% are due to Firefox. This is one of the
reasons that we would like to revise it. But in that case, a vbscript
may not be a good substitute since it's only supported by IE. A
Server- side technique is probably a better solution to this problem.

You guys both asked about the performance bottlenecks. It happened
when a user tried to send anyone a note, the lock block number in SQL
Server would go extremely high at the time that it was being send.

This has nothing to do with the application code

(approx. three times than usual) I have checked with our IT guy and he
said our bandwidth and DB hardware are both good to go. I am not sure
which exact point(s) results in these terrible spikes but I can tell
you we called a stored procedure that inserts a row for the content in
the table. Period. How could such a simple command result in a
tremendously poor performance?

One word: deadlock. Look it up in SQL Books Online

So, sounds like I have to choose COM isn't it?

No. Again, this particular issue has nothing to do with the code executing
your stored procedure. It's a deadlock condition in your sql server.

 

[Bob Barrows [MVP]]

This sounds as if you are using dynamic sql to handle he user input.
As you are finding out this is a bad idea. You need to implement a
two-phase approach:
1. Validate all user input in server-side code. Do not depend on
client-side validation. If possible, identify malicious input and
kick the maliciouls users out of the system
2. Use parameters instead of dynamic sql

Here are some links about sql injection

Oops

http://mvp.unixwiz.net/techtips/sql-injection.html
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=23
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf

See here for a better, more secure way to execute your queries by using
parameter markers:
http://groups-beta.google.com/group/microsoft.public.inetserver.asp.db/msg/72e36562fee7804e

Personally, I prefer using stored procedures
http://groups.google.com/group/microsoft.public.scripting.vbscript/msg/61fedf4e1efd63a6

And if you are using dynamic sql inside your stored procedure:
http://www.sommarskog.se/dynamic_sql.html

 

[Evertjan.]

wrote on 29 jun 2007 in microsoft.public.inetserver.asp.general:

The core is written in ASP/Javascript and it
could be included in any of our webpages when it's required for the
development. The security issue is because 50% of it was written in
Javascript, and it's visible when one choose to view source in the
browser, ....

Despite the warnings given, you are still using the wrong terminology,
using the word "javascript" for "clientside javascript", while most readers
of this NG will understand "ASP/javascript" as "serverside javascript under
ASP".

In the same way, ASP itself being just a platform, the term ASP needs
elaboration on the serverside language used, and ASP does NOT stand for
"ASP vbscript" as such.

Using clientside javascript as part of any security scheme is a wrong
aproach, period. Clientside javascript should only be used for dynamic
features and for giving the user a helping hand on a [perhaps ASP
serverside language rendered] html page.

 

[Anthony Jones]

Thank you Anthony and Bob, I appreciate your opinion.

Let me elaborate more about my previous questions. The system that I
was asking is more like an instant note sending system only available
to our website members. The core is written in ASP/Javascript and it
could be included in any of our webpages when it's required for the
development. The security issue is because 50% of it was written in
Javascript, and it's visible when one choose to view source in the
browser, some people begin putting some malicious codes inside the
subject/content and thereby attempting to hack our system. Since our
users are all over the Internet, it is probably not feasible to force
them install software if they would like to retrieve/send notes
online.

Yes, as you mentioned the Javascript is the client-side code. Since
it's client side, it implies the module may not function properly if
one turns off its Javascript support, such as using Firefox as the
default. We have received so many e-mails asking how come they cannot
use the note system, and 99.9% are due to Firefox. This is one of the
reasons that we would like to revise it. But in that case, a vbscript
may not be a good substitute since it's only supported by IE. A Server-
side technique is probably a better solution to this problem.

You guys both asked about the performance bottlenecks. It happened
when a user tried to send anyone a note, the lock block number in SQL
Server would go extremely high at the time that it was being send.
(approx. three times than usual) I have checked with our IT guy and he
said our bandwidth and DB hardware are both good to go. I am not sure
which exact point(s) results in these terrible spikes but I can tell
you we called a stored procedure that inserts a row for the content in
the table. Period. How could such a simple command result in a
tremendously poor performance?


So, sounds like I have to choose COM isn't it? Unfortunately I am not
a very professional C++ writer since I only touched it when at school.
But if this is the only one solution I guess there's no room for me to
say I am not familiar....

Fundementally you have three problems. A binary component doesn't feature
in the solution to any of them

1) Script disabled clients can't use your notes system.

You need a simple HTML form posted to the server and move the notes logic to
the server.

2) Validating user entered text to avoid Javascript injection

NEVER send user entered text to a client without first encoding it with
Server.HTMLEncode.

3) A SQL performance problem

Can't really help with that one without more info. Like Bob said it would
be worth looking up deadlocking but also check that you have reasonable
Indexes in place.

 

[Mark J. McGinty]

Thank you Anthony and Bob, I appreciate your opinion.

Let me elaborate more about my previous questions. The system that I
was asking is more like an instant note sending system only available
to our website members. The core is written in ASP/Javascript and it
could be included in any of our webpages when it's required for the
development. The security issue is because 50% of it was written in
Javascript, and it's visible when one choose to view source in the
browser, some people begin putting some malicious codes inside the
subject/content and thereby attempting to hack our system. Since our
users are all over the Internet, it is probably not feasible to force
them install software if they would like to retrieve/send notes
online.

Yes, as you mentioned the Javascript is the client-side code. Since
it's client side, it implies the module may not function properly if
one turns off its Javascript support, such as using Firefox as the
default. We have received so many e-mails asking how come they cannot
use the note system, and 99.9% are due to Firefox. This is one of the
reasons that we would like to revise it. But in that case, a vbscript
may not be a good substitute since it's only supported by IE. A Server-
side technique is probably a better solution to this problem.

You guys both asked about the performance bottlenecks. It happened
when a user tried to send anyone a note, the lock block number in SQL
Server would go extremely high at the time that it was being send.
(approx. three times than usual) I have checked with our IT guy and he
said our bandwidth and DB hardware are both good to go. I am not sure
which exact point(s) results in these terrible spikes but I can tell
you we called a stored procedure that inserts a row for the content in
the table. Period. How could such a simple command result in a
tremendously poor performance?

An insert statement may look deceptively simple, but its complexity to the
server depends on indexes affected, DRI, and any code invoked by it. Do you
have numerous and/or composite indexes defined? Multiple foreign keys?
Complex constraints? Intensive and/or recursive triggers?

You need to look at the big picture as a whole, considering all mechanisms
that impact insert performance, and then analyze each of those mechanisms
individually to isolate the bottleneck Try defining just the table (no
triggers or constraints or indexes besides just a PK) then add the rest of
those things one by one, comparing lock overhead incurred by each as you go.

One thing in particular that will kill performance and generate large
numbers of locks is a poorly chosen clustered index on an active table. The
server maintains the rows of data in physical order of the clustered index
key, which will force it to move rows that would otherwise be uninvolved,
when a clustered key value for a given row changes. Expectedly, clustered
indexes involving columns subject to frequent changes will incur substantial
load, that will increase exponentially as you approach activity peaks. Also
expectedly, composite clustered indexes will tend to exacerbate this
ffect -- you need a really compelling reason to even consider a composite
clustered index.

So my suggestion would be to take a good look at the schema involved; make
sure the reasoning that underlies your indexing strategy is sound; be
cognisant of the load that thesr constructs incur.


-Mark


(btw, I agree completely that you have practically nothing to gain from a
C++ rewrite.)

 

[tanya.wang]

Sorry for my late reply...

I have checked the schema of my notes table.

There is a primary key clustered on noteid with fillfactor=90 on
primary.
A FK to check if the receiver exists in our member table. on delete
cascade and on update cascade.
Three default constraints indicating note type, create date, and if
this note has been read.
No DB triggers associated with this table.

I wrote a sp "Add_Notes_sp " to insert into data whenever it's been
called for sending notes.
On my asp page, I simply called
conn.execute "Add_Notes_sp " & parameter1 & "," & parameter 2 & ...

If the fundamental problem results from the SQL server and DB schema,
then I would understand why it's no help to re-write in C++. If I took
the right idea - the system should be still slow since I still need to
call DB and sp after the rewrite.

Thank you very much for all your suggestions. I really appreciate
that.

 

[Evertjan.]

wrote on 03 jul 2007 in microsoft.public.inetserver.asp.general:

Sorry for my late reply...

A reply?

This is usenet and not email,
and if you do not quote,
as is rightly required by Netiquette,
how are we to know what you are going on about?

Even a prompt reply would need some quoting.

 

[Mark J. McGinty]

Since most of us likely use Usenet clients that maintain the context of
ongoing threads, I'd think quoting to be pretty much a non-issue to all but
the most anal-retentive of us.

Isn't there anything in netiquette about posting to the Usenet for the sole
purpose of making a point about netiquette? If not, I'd call it a miserable
failure on the part of whomever its collective authors are, because posting
something that is 100% admonition and 0% content is perhaps the rudest thing
that happens here.

(To the OP, pay no mind to the 'netiquette police', his views are mostly his
own, and even if any are widely shared, no one else goes out of their way to
promote them.)


-Mark

 

[Evertjan.]

Mark J. McGinty wrote on 04 jul 2007 in
microsoft.public.inetserver.asp.general:

Since most of us likely use Usenet clients that maintain the context
of ongoing threads, I'd think quoting to be pretty much a non-issue to
all but the most anal-retentive of us.

Did you do a survey or do you define "most of us"
as the people that likely follow your idea's, Mark?

"anal-retentive of us"

Is this the preferred vocabulary on usenet-as-you-see-it?

Do you hink that an argument should be won
by degrading others with words like that.

If so, I pity you.