World: r3wp

this is a real use case, not just a question in the air... I have 
to help a client with a problem they have.  not a cheyenne bug, but 
the way its being used by their clients.

I'm not sure what you mean precisely by "to trap connections" and 
also "current context of the server"? Are you talking about hacking 
  the HTTP layer in Cheyenne?

I need to be able to verify a connection from a client right when 
it happens.  so that I can refuse it based on some conditions and 
do some other client-internal stuff.

Like IP address?

no, based on the current state of connections on the server.  quantity 
of connections for example.

http is stateles .. so what are you going to measure?

Max, that would require writing a specific module for Cheyenne. Connections 
number can be measured by doing a : length? system/ports/wait-list 
(and subtracting worker processes local connections).

how many connections are actively being served , time since they 
connected (to enable better timeout handling), etc.

Cheyenne network I/O layer (UniServe) tracks connections timestamps 
and manage timeouts automatically.

ok and is there a document which explains easily how to create and 
link a module at that level?

and if users just let their connections timeout instead of logging 
out ....

You can find a short doc for Cheyenne's mods API in %Cheyenne/docs/developer-guide.html.

If you want to manage connections by yourself, you need to dive deep 
into UniServe's engine to avoid conflicts with its own connections 
management rules.

ok, is there anything documented on that side? or is it (what I expect) 
seek & destroy into the code itself?

There's a UniServe user documentation, but UniServe internals are 
not documented.

ok. thanks, you`ve already helped me save some time  :-)

Maybe there's a more simple solution for what you want to achieve 
than hacking UniServe? I still don't get exactly what's your goal. 
Is it debugging? Is it adding a new feature to Cheyenne?

explique lui en FR ca ira plus vite lol "bonsoir dock ca boum ?"

Sorry, this group is for discussion in english only which is the 
common language shared by all AltMe users.

Max, not sure that it can help you, but you can open a live REBOL 
console connected to a running Cheyenne instance (only from localhost). 
You can then use the NETSTAT function to list all active connections 
in realtime. The client for connecting is : %UniServe/clients/rconsole.r

If you try that, just beware of a few things :

- don't use QUIT or you'll close Cheyenne, just send a CTRL-C to 
exit the console session.

- avoid probing things like UniServe's ports, they contains several 
circular references that, once molded, will produce huge amount of 
printed text and can hang on the server for several seconds (or minutes 
in the worst case).

rconsole is cool, it will allow me to follow development from the 
outside.

I mean follow if the changes are really doing what they should  :-)

I've use it a few times to hotpatch running Cheyenne instances.

<used>

Hi, Doc .. is the latest binary not totally the same as sources? 
It seems it doesn't look into lib32 like it does if I run from sources

It should be the same. Did you applied the patch I gave you in Linux 
group on the sources?

The source version worked without any patches already.. I can't apply 
them to binary version because I can't enpro it.. I am still not 
an owner of Rebol or SDK

I could encap a new version if you need, just let me know which encapper 
you prefer : enpro or enface?

If I understand right enpro is without view and enface is not.. I 
would need the one without

That's right. Enface requires a few additional libs installed in 
order to work (like Xlib).

I would be really gratefull if you could make new build :)

DEBUG: I tried the debug-banner stuff but it doesn't work.

** Script Error : debug-banner has no value 
	** Where: rsp-script 

	** Near:  [debug-banner/active?: yes

Prefixing it with debug/ doesn't work as well.

Any idea?

Tested here, same error as you. The word is declared inside an object 
and is not exported in global space.

It looks like it's more complicated to activate the debug mode from 
within a RSP script than it seemed first.

Ok. I use the workaround that I'm logged into the server and use 
a "tail -f trace.log" to see what's happening.

Works.

doc, my I suggest a new feature?

sure

a way for a service to be asked permission to allow connection from 
the uniserve POV.

something like on-allow-connection? within the service api.

can services add data within the /shared object?

this way, the uniserve can ask the service if all is set for handling 
requests... there are hundreds of uses for this... time tables, required 
header fields, etc etc.

in this case connection limits based on service specific requirements, 
like detecting deadlocks in requests ... which uniserve obviously 
can't figure out by itself.

if the service is in an state it can deduce as problematic, it can 
directly report it to the client attempting to connect to cheyenne, 
before any data is even read.

in my case, the services have dependencies on remote servers... so 
its possible the remote server is down, I want to report this to 
the client connecting to cheyenne right away, not wait for a double 
timeout to occur, which means the service can be down for a very 
long while before cheyenne client connections start reporting error.

in this case, I can easily keep statistics on my service, noting 
access times and concurrent connections, detecting if something is 
preventing the service from actually handling calls.

Shared object: yes, you can add data there, it's for sharing data/code 
between all services.