"Jim Starkey" <jas@...> wrote in message
news:42B05BD6.2020902@......

> Aleksey Karyakin wrote:
>
>>However, it is possible to send interruption request using the
>>original socket. I even believe it can be done in the current SS

TCP

>>listener without mass modification. Current TCP listener
>>implementation receives and dispatches packets asynchronously of
>>other threads executing them. So it can happily receive

interruption

>>request and notify the worker thread to stop.
>>The client side should use some per-socket synchronization to keep
>>data separate and submit cancel requests from a different thread
>>since the primary thread is blocked.
>>
>>
> Not without redesigning the wire protocol, server code, and remote
> interface and changing the layering within the server. It also

Nothing has to be redesigned, really. In theory, there should appear
new message type in remote protocol, but the existing one for
isc_free_statement () could fit. Overall client interface change is
indeed adding a new constant in ibase.h as Borland did. BTW, as far
as I understand, IB6.5 still opens separate connection to cancel
queries.

> precludes extending the interruption mechanism to let a dba kill
> selected requests.

Interruption mechanism in the engine is the same
(gds_cancel_operation) and it is operational for a few years,
however, only for SuperServer. The absent part is the means of
delivery of the cancel request from a client to server. Cancelling
users' own queries is easy and can be done over a weekend.

In short:

-- it solves the problem of killing long-running queries by users
themselves
-- it is easy to implement in SS code
-- it has no security implications
-- it does not require a protocol to exchange a token
-- it can be easily integrated with third-party tools and interfaces

The main problem I see is the lack of Classic (single-threaded
server) support. Isn't Classic doomed to extinction? Anyway, Classic
can't merely be stopped properly if it executes a query.

The case of admin killing arbitrary queries is quite different and it
requires different approach. The main problems are identification of
those queries and security. Suppose there is a token for every
running query (there certainly is one). How does admin get to know
what its value is? There is little sense in telling the token to the
client since he can just forget it (a bad programmer surely will).
The only way for admin to identify suspect queries is browsing over
currently execution activity and choose the one based on some
criteria, for example, client IP, execution time or blocking state.
View-based approach comes to mind (another deja-vu?). Okey, who are
allowed to kill queries issued by others? Sysdba only? Or should
there be a special server-wide grantable priviledge?

>>I would like events to use the original socket as well.
>>
> Again, it is very difficult for two independent threads share a

single

> stream oriented communication pipe. Not impossible, but it must be
> designed in from the beginning, which was difficult because threads

Regarding events, there may be reasonable sense in separate
connection.

> didn't exist when the event mechanism was designed. Sockets are

not

> inherently expensive. The problem is that some systems unfortunate
> limits on the number of sockets, which can be address by not using

those

> platforms for servers.

The real problem is not in the cost but the diffuculty to
consistently manage two different communication channels between a
single client and a single server. The original events implementation
clearly shows its problems - it works bad with firewalls, NAT,
several network interfaces, subject to blocking and so on.

>>Yes, the current event logic has a similar security problem since
>>there is no authentication of secondary connections. There is a

time

>>slice after a server opens the secondary socket and until the

current

>>client connects to it when any TCP-enabled program in the world may
>>connect instead and hijack the events.
>>
>>
> That will cause the client to fail so no events can be queued. The
> hijacker is going to be stuck with an inactive port, which is

pretty

Yes, you are right, fortunately.

> boring. I suppose we should at least make sure that the guy

connecting

> to the auxiliary connect is from the proper IP address. But the

client

> is still going to get screwed, I fear.

IP checking/advertising doesn't work with NAT. Some big random number
like GUID or generated encryption key would be ok.

>>Why tokens? Use statement handle to identify running statement in

the

>>same program if the program wants to cooperate in request

cancelling

>>by itself. If a program doesn't want to cooperate to manage its
>>running queries, it will hardly provide you any tokens as well.
>>
> Handles don't cross layers.

Hmm, their values don't. Object identifiers represented by them do.
The idea was that a client can identify its own request by providing
statement handle to the client interface.

Regards,
Aleksey Karyakin