Knowing the connection status

[Jon <jo...@resfeber.se>]

Hi list,

I'm currently working on a project that uses a closed source C api. I know the functions and what they return but have no clue what happends in the background. To be able to use this with mod_perl I've made a module using perlxs that basicly is a wrapper around the API's functions. This API connects to a server and can only handle one connection at the time so my wrapper needs to know if it is connected and avoid connecting again if it allready is connected. There is no reasonable way I can test my connection status, ie there is no get_connection_status or equivalent function I can call. Trying to fetch or send data if there is no connection will force me to wait for the timeout which I can't do since all scripts using the API will be extremly slow then. The connect function is very slow too, it takes a few secs to do the connect so I don't want to do extra connects either, plus it seems to result in core dumps when I try to do connect if I'm allready connected.

I was first thinking about using a global variable in the wrapper's connect function but I'm not sure what would happend if the script crashes, will the httpd process die and the global variable be reseted or will it be set to CONNECTED when the next request comes to that child?

So to stop my ramble and get on with my question, how should I approach this in a way that guarantees that I'll only do connect/disconnect if needed and also be able to keep track of my status in a safe way? If you're thinking refuse to do it, go to the makers of the API and beat them untill they fix it up or snort/strace the API and make your own API based of what they send, I've allready thought about it and I've come to the conclusion they're not options :)

/Jon

Re: Knowing the connection status

[Lupe Christoph <lu...@lupe-christoph.de>]

Please wrap your extremely long lines!

On Thursday, 2002-11-07 at 09:47:12 +0100, Jon wrote:

> I'm currently working on a project that uses a closed source C api. I know the functions and what they return but have no clue what happends in the background. To be able to use this with mod_perl I've made a module using perlxs that basicly is a wrapper around the API's functions. This API connects to a server and can only handle one connection at the time so my wrapper needs to know if it is connected and avoid connecting again if it allready is connected. There is no reasonable way I can test my connection status, ie there is no get_connection_status or equivalent function I can call. Trying to fetch or send data if there is no connection will force me to wait for the timeout which I can't do since all scripts using the API will be extremly slow then. The connect function is very slow too, it takes a few secs to do the connect so I don't want to do extra connects either, plus it seems to result in core dumps when I try to do connect if I'm allready connected.

> I was first thinking about using a global variable in the wrapper's connect function but I'm not sure what would happend if the script crashes, will the httpd process die and the global variable be reseted or will it be set to CONNECTED when the next request comes to that child?

If you have a C global variable, it is local to the process. If your
Perl code dies or exits, the http process will go and take that variable
with it. If you catch a die in an eval, the variable will stay, of
course.

Are you saying that each client side can only have one connection, or is
the server limited to one connection? OIf that is the case, you would
need a system-global status in an intermediate server (between Apache
and whatever the API talks to).

> So to stop my ramble and get on with my question, how should I approach this in a way that guarantees that I'll only do connect/disconnect if needed and also be able to keep track of my status in a safe way? If you're thinking refuse to do it, go to the makers of the API and beat them untill they fix it up or snort/strace the API and make your own API based of what they send, I've allready thought about it and I've come to the conclusion they're not options :)

If you have one connection per client, you can do lazy evaluation, i.e.
connect whenever works needs to be done, and cache the connection until
the Apache process exits.

HTH,
Lupe Christoph
-- 
| lupe@lupe-christoph.de       |           http://www.lupe-christoph.de/ |
| Big Misunderstandings #6398: The Titanic was not supposed to be        |
| unsinkable. The designer had a speech impediment. He said: "I have     |
| thith great unthinkable conthept ..."                                  |