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
precludes extending the interruption mechanism to let a dba kill
selected requests.

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

>
>
>>Going back to the security question raised above, let's try a
>>
>>
>different
>
>
>>tack. Rather than trying to verify permissions, why don't we use an
>>unforgeable token like a guid? Then, if we see a valid token, we
>>
>>
>can
>
>
>>safely assume that it originated from the client wishing to snuff
>>
>>
>out
>
>
>>his request.
>>
>>
>
>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
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.

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

>Not a big deal. If a client program itself wants to cancel its
>request, it rather never use isc_dsql_execute_immediate. If someone
>else wants to cancel others' running requests, it is no matter which
>exact statement handle/token was used (if used at all).
>
>
>
>

No, this is a problem worth solving.


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376