FastCGI Handling multiple requests without a library - fastcgi

I would like to know how should I handle multiple requests with one instance of a program, by that I mean, a fcgi program is supposed to continue running after one request has been answered, the problem is, how do I know that the current request data inside the environment variables is not the one from the last request.
My idea is to use setenv to set the environment variables to NULL after parsing them so when they are not NULL it means that the server has set them to the values of the new request but I'm not sure if this is the way it is supposed to be done.
I know that there are libraries that handle this stuff and that it is safer to use those, but right now my objective is just to learn how fcgi works behind the libraries

It's not clear what do you mean by 'multiple requests' in your question.
Based on your description I assume that you expect that your FastCgi app is still alive after processing the first request and can handle another request.
But that's the nature of FastCgi: a single program/service is running in an 'infinite loop' and handle all incoming requests. It's guaranteed by the FastCGI design that the Request object (including all environment variables) are properly set.
The old CGI works in an opposite way: a new process (i.e. instance) of the CGI program is spawned on each request.
It's highly likely that you keen on concurrent requests. But that's still possible.
Unfortunately you haven't mentioned neither server type nor programming language nor OS which you work with.
It's really easy to find examples for handling concurrent requests on Unix systems in C/C++.
You've mentioned that you wouldn't like to use any libraries but I believe you have to use at least one which implements the FastCGI interface. The most commonly used is fcgiapp by Open Market.
Handling concurrent requests is achieved by the multi-threading technique which is called Locks.
I'm a 'Windows guy' so this is my example for WINAPI and C:
#define THREAD_COUNT 20
#define FAST_CGI_SOCKET ":9345"
#include <locale.h>
#include "fcgiapp.h"
CRITICAL_SECTION accept_mutex;
DWORD WINAPI requestHandler()
{
int code;
FCGX_Request request;
FCGX_InitRequest(&request, 0, 0);
for (;;)
{
EnterCriticalSection(&accept_mutex);
code = FCGX_Accept_r(&request);
LeaveCriticalSection(&accept_mutex);
if (code < 0) break;
// TODO handle request
FCGX_Finish_r(&request);
}
return 0;
}
void initFastCgi() {
FCGX_Init();
FCGX_OpenSocket(FAST_CGI_SOCKET, SOMAXCONN);
}
void startThreadsAndWait() {
int i;
HANDLE threads[THREAD_COUNT];
InitializeCriticalSection(&accept_mutex);
for (i = 0; i < THREAD_COUNT; i++) {
threads[i] = CreateThread(NULL, 0, &requestHandler, NULL, 0, NULL);
}
for (i = 0; i < THREAD_COUNT; i++) {
WaitForSingleObject(threads[i], INFINITE);
}
for (i = 0; i < THREAD_COUNT; i++) {
CloseHandle(threads[i]);
}
}
void appStart() {
setlocale(LC_ALL, "en_US.utf8");
initFastCgi();
}
void freeResources() {
}
void appFinish() {
freeResources();
}
int main(void)
{
appStart();
startThreadsAndWait();
appFinish();
return 0;
}
All the magic is around accept_mutex.
Hope that will help even if you use a different OS or a programming language

Related

starting a process with exactly the same address structure as previous openning

Is it possible to start a process in windows with exactly the same address structure as the previous opening of the process?
To clarify the goal of this question I should mention that I use cheatengine (http://www.cheatengine.org/) to cheat some games! It includes several iterations to find a parameter (e.g. ammunition) and freeze it. However, each time I restart the game, since the memory structure of the game changes, I need to go through the time-consuming iterations again. So, if there were a method bring up the game exactly with the same memory structure as before, I wouldn't need going through iterations.
Not to say it's impossible, but this is essentially too much work due to the dynamic memory allocation routines the process will be using including the new operator and malloc(). Additionally when the DLL's imported by the executable are loaded into memory they have a preferred imagebase but if that address is already used, the OS will load it into a different memory location. Additionally Address Space Layout Randomization (ASLR) can be enabled on the process which is a security measure that randomizes the memory address of code sections.
The solution to your problem is much easier then what you're asking. To defeat the dynamic memory allocation described above you can still resolve the correct address of a variable by utilizing:
Relative offsets from module bases
Multi-level pointers
Pattern Scanning
Cheat Engine has all 3 of these built into it. When you save an address to your table is often saves it as a module + relative offset. You can pointer scan for the address and save it as a multilevel pointer or reverse the pointer yourself and manually place it in the table. Pattern scanning is achieved by using a CE Script, which you can put right in the Cheat Table.
In this case the ammo variable, may be a "static address" which means it's relative to the base address of the module. you may see it listed in Cheat Engine as "client.dll + 0xDEADCODE". You simply get the base address of the module at runtime and add the relative offset.
If you're looking to make an external hack in C++ you can get started like this.
In an external hack you do this by walking a ToolHelp32Snapshot:
uintptr_t GetModuleBase(const wchar_t * ModuleName, DWORD ProcessId) {
// This structure contains lots of goodies about a module
MODULEENTRY32 ModuleEntry = { 0 };
// Grab a snapshot of all the modules in the specified process
HANDLE SnapShot = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, ProcessId);
if (!SnapShot)
return NULL;
// You have to initialize the size, otherwise it will not work
ModuleEntry.dwSize = sizeof(ModuleEntry);
// Get the first module in the process
if (!Module32First(SnapShot, &ModuleEntry))
return NULL;
do {
// Check if the module name matches the one we're looking for
if (!wcscmp(ModuleEntry.szModule, ModuleName)) {
// If it does, close the snapshot handle and return the base address
CloseHandle(SnapShot);
return (DWORD)ModuleEntry.modBaseAddr;
}
// Grab the next module in the snapshot
} while (Module32Next(SnapShot, &ModuleEntry));
// We couldn't find the specified module, so return NULL
CloseHandle(SnapShot);
return NULL;
}
To get the Process ID you would do:
bool GetPid(const wchar_t* targetProcess, DWORD* procID)
{
HANDLE snap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
if (snap && snap != INVALID_HANDLE_VALUE)
{
PROCESSENTRY32 pe;
pe.dwSize = sizeof(pe);
if (Process32First(snap, &pe))
{
do
{
if (!wcscmp(pe.szExeFile, targetProcess))
{
CloseHandle(snap);
*procID = pe.th32ProcessID;
return true;
}
} while (Process32Next(snap, &pe));
}
}
return false;
}
Using my example you would combine these functions and do:
DWORD procId;
GetPid(L"game.exe", &procId);
uintptr_t modBaseAddr = GetModuleBase(L"client.dll", procId);
uintptr_t ammoAddr = modBaseAddr + 0xDEADCODE;
If the address is not "static" you can find a pointer to it, the base address of the pointer must be static and then you just follow the above guide, and dereference each level of the pointer and add an offset.
Of course I have a function for that too :)
uintptr_t FindDmaAddy(HANDLE hProcHandle, uintptr_t BaseAddress, uintptr_t Offsets[], int PointerLevel)
{
uintptr_t pointer = BaseAddress;
uintptr_t pTemp;
uintptr_t pointerAddr;
for (int i = 0; i < PointerLevel; i++)
{
if (i == 0)
{
ReadProcessMemory(hProcHandle, (LPCVOID)pointer, &pTemp, sizeof(pTemp), NULL);
}
pointerAddr = pTemp + Offsets[i];
ReadProcessMemory(hProcHandle, (LPCVOID)pointerAddr, &pTemp, sizeof(pTemp), NULL);
}
return pointerAddr;
}
I would highly recommend watching some Youtube tutorials to see how it's done, much better explained in video format.

Dart: update UI during long computation

I have a small dart script which I intend to use in the following way:
CanvasElement canvas;
void main() {
canvas = querySelector('#canvas');
querySelector('#start-button').onClick.listen((_) => work());
}
void work() {
var state; // some state of the computation
for (int i = 0; i < /*big number*/; i++) {
// do some long computation
render(state); // display intermediate result visualisation on canvas
}
}
void render(var state) {
canvas.context2D.... // draw on canvas based on state
}
that is listen for click on a button and on that click execute some long computation and from that computation display some intermediate results on the canvas live as the computation progresses.
However, this does not work - the canvas is updated only once after the whole computation completes.
Why is that? How should I arrange my code to work in a live, responsive way?
One of solutions would be to put parts of your long computation into dart's event loop, i.e. queuing computation by waiting for a future it immediately return.
Please, see sample on DartPad.
But if you have lots of heavy computations, I think it would be better to start a new isolate and communicate with it about it's state.
Update
Here is almost, not exactly the same, work function, rewritten without using await, maybe it would be a bit clearer how it works:
for (int i = 0; i < 200; i++) {
new Future(()=>compute(i)).then((double result)=>render(i+result*50));
}
Here, we are actually creating 200 futures, queuing them into event loop (Future constructor does that), and registering a personal callback for each one.

How do you run a DART application as a windows service?

I've been researching the possibility of using the DART language for my next project. The only thing really holding me back at this point is that I'm unable to find a way to run a DART application as a windows service. I have run searches on Google and read through much of the documentation on the DART website. Most of the information I found was related to creating a server in DART but nothing regarding windows services.
Can someone either point me at directions or detail the steps necessary to do so?
Thanks,
Jon
=== Latest Update ===
My original answer consisted of using C and Dart FFI to boostrap the Windows Service. However, none of this is really needed as a much, much, simpler solution can be had by using Docker with Windows Containers.
Instead of actually running the application as a Windows Service, the alternative is to compile it to an executable Windows console application, create a Docker file and a Windows Docker image that will include that application. On the server you will need docker and you can simply run the image with a --restart option. To test this out, Windows 10 supports Docker with Windows containers.
So, the simple solution is, we don't really need to run Dart code as a Windows Service, because we can run it as a docker container on the server.
=== Original Answer ===
I am arriving really late to the game, but I figured a way around this problem without having to use 3rd party applications.
My solution is kind of an hack, but hey, it works. I am compiling the dart application as an executable and then registering it as a Windows Service, using sc.exe create. The issue with sc.exe create is that the main function of the application needs to perform some extra steps to inform Windows that it is running. If this isn't done, Windows service gets stuck in a "Starting state".
I don't think there is a pub package available to perform this duty. However, there are 2 things we can use: Dart:FFI, and the following article from Mohit Arora that explains how to create a Windows Service in C++. https://www.codeproject.com/Articles/499465/Simple-Windows-Service-in-Cplusplus
I grabbed Mohit's code and made a ton of changes (including backporting it to C, because... C++)
C
Here's the full code of the Service.c file:
// Provides an API for Dart console applications to
// integrate themselves as Windows Services
// The entry point to this API is the Init(...)
// function at the bottom of this file.
// The Init(...) function registers the ServiceMain(...)
// function as the actual windows service function.
// the ServiceMain function does the following:
//
// 1. Registers the ServiceCtrlHandler(...) function
// as the service control handler, which is essentially
// tasked to handle control requests (in this case we
// are only handling the request to stop the service).
//
// 2. Creates an event object that and then waits indefinitely
// for the event to be set.
//
// The ServiceCtrlHandler(...) function responds to a
// close request by setting the event created by the
// ServiceMain(...) function, essentially freeing
// the latter from the indefinite wait and terminating
// it.
// The functions in this file don't actually
// do any work, but keep the Windows Service
// alive. The work be initiated by the calling
// application either before or after the call to Init(...).
// Because this was developed for the purpose
// of enabling Dart applications to run as
// Windows Services, it it the Dart Application
// that needs to call Init(...) using Dart FFI.
// It must also be the Dart Application to
// spawn an isolate that does the actual work
// before the call to Init(...)
#include <Windows.h>
#include <tchar.h>
#include "service.h"
SERVICE_STATUS g_ServiceStatus = { 0 };
SERVICE_STATUS_HANDLE g_StatusHandle = NULL;
HANDLE g_ServiceStopEvent = INVALID_HANDLE_VALUE;
LPWSTR w_service_name;
void UpdateStatus(
DWORD newState,
DWORD checkPoint,
DWORD exitCode,
DWORD controlsAccepted)
{
g_ServiceStatus.dwControlsAccepted = controlsAccepted;
g_ServiceStatus.dwCurrentState = newState;
g_ServiceStatus.dwWin32ExitCode = exitCode;
g_ServiceStatus.dwCheckPoint = checkPoint;
SetServiceStatus(g_StatusHandle, &g_ServiceStatus);
}
// Responds to control events. This implementation is
// only responding to the SERVICE_CONTROL_STOP event
// This method signals the ServiceMain function
// that it can stop waiting before terminating.
void WINAPI ServiceCtrlHandler(DWORD CtrlCode)
{
if (CtrlCode != SERVICE_CONTROL_STOP || g_ServiceStatus.dwCurrentState != SERVICE_RUNNING)
return;
UpdateStatus(SERVICE_STOP_PENDING, 4, 0, 0);
SetEvent(g_ServiceStopEvent);
}
void InitServiceStatus()
{
ZeroMemory(&g_ServiceStatus, sizeof(g_ServiceStatus));
g_ServiceStatus.dwServiceType = SERVICE_WIN32_OWN_PROCESS;
g_ServiceStatus.dwServiceSpecificExitCode = 0;
UpdateStatus(SERVICE_START_PENDING, 0, 0, 0);
}
// This function essentially creates an event object
// and enters a holding pattern until that event object
// is set by the ServiceCtrlHandler(...) in response
// to a close request.
// The function doesn't actually do any work,
// except to keep the Windows Service alive.
void WINAPI ServiceMain(DWORD argc, LPTSTR* argv)
{
g_StatusHandle = RegisterServiceCtrlHandler(w_service_name, ServiceCtrlHandler);
if (g_StatusHandle == NULL)
return;
InitServiceStatus();
g_ServiceStopEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
if (g_ServiceStopEvent == NULL)
{
UpdateStatus(SERVICE_STOPPED, 1, GetLastError(), 0);
return;
}
UpdateStatus(SERVICE_RUNNING, 0, 0, SERVICE_ACCEPT_STOP);
while (WaitForSingleObject(g_ServiceStopEvent, INFINITE) != WAIT_OBJECT_0)
;
CloseHandle(g_ServiceStopEvent);
UpdateStatus(SERVICE_STOPPED, 3, 0, 0);
}
LPWSTR get_service_name(const char* service_name)
{
int max_count = strlen(service_name);
int size = max_count + 1;
LPWSTR ret = malloc(sizeof(wchar_t) * size);
size_t outSize;
mbstowcs_s(&outSize, ret, size, service_name, max_count);
return ret;
}
/// This is the entry point that should be called
/// by the Dart application (or any application
/// of a similar kind of platform) in order to
/// integrate itself as a Windows Service.
/// It registers the ServiceMain(...) function
/// as the service main function. Please consult
/// the comments at that function to understand
/// what it does.
int init(const char* service_name)
{
w_service_name = get_service_name(service_name);
SERVICE_TABLE_ENTRY ServiceTable[] =
{
{w_service_name, (LPSERVICE_MAIN_FUNCTION)ServiceMain},
{NULL, NULL}
};
if (StartServiceCtrlDispatcher(ServiceTable) == FALSE)
return GetLastError();
}
The Service.h header file is, naturally, a lot smaller:
#pragma once
#ifdef WINSERVICE_EXPORTS
#define WINSERVICE_API __declspec(dllexport)
#else
#define WINSERVICE_API __declspec(dllimport)
#endif
WINSERVICE_API int init(const char* service_name);
Just make sure you add WINSERVICE_EXPORTS to one of the definitions or replace it by the corresponding definition in your project.
Dart
I also needed to perform a few changes from the Dart side. Here's my prototype:
import 'dart:ffi' as ffi;
import 'dart:io';
import 'dart:isolate';
import 'package:ffi/ffi.dart';
import 'package:grpc/grpc.dart' as grpc;
// These two types represent the
// Init(...) function of the C API
typedef init_func = ffi.Int32 Function(ffi.Pointer<Utf8>);
typedef Init = int Function(ffi.Pointer<Utf8>);
// Entry point to the Dart application.
// When run as a Windows Service,
// this is still the entry point.
// This code is not embeded but is started
// as a regular console application.
void main() async {
final init = createInit();
// Starts the actual work in a separate Isolate
await Isolate.spawn(run, 'message');
final serviceName = Utf8.toUtf8('MProto_Server_from_Dart');
// calls the Init(...) function
var result = init(serviceName);
if (result != 0) return;
// blocks this Isolate indefinitely from continuing
while (true) {
sleep(Duration(days: 365));
}
}
// Creates the instance of the proxy to the Init(...)
// function.
Init createInit() {
final path =
r'[PATH to the C compiled DLL]';
final dylib = ffi.DynamicLibrary.open(path);
// ignore: omit_local_variable_types
final Init init =
dylib.lookup<ffi.NativeFunction<init_func>>('init').asFunction();
return init;
}
// Performs the actual work that needs to
// be done, in this case, we are hosting
// a gRPC service, but this should
// work with any other kind of
// payload, namely other types of
// http services.
void run(String message) async {
print('inside isolate');
var server = grpc.Server(
[
// my service classes
],
);
await server.serve(port: 5001);
}
There's no difference in using Dart for a Windows service as any other executable; you just need to call dart.exe with the correct arguments.
However, Windows doesn't support running arbitrary exes as Windows Services, as they require a little metadata/bootstrapping. I've had good experiences with NSSM - the Non-Sucking Service Manager. In the comments, SC.exe was suggested; but I was unable to get it running on the latest version of Windows Server :(
look at dart package dart_windows_service_support
He use dart:ffi and a dll file enables dart to run in Windows service mode
https://pub.dev/packages/dart_windows_service_support
Use WinSW
WinSW wraps and manages any application as a Windows service.
Create the service directory in your project.
Find the latest release of WinSW on GitHub, you are very likely looking specifically for WinSW-x64.exe. Copy this file under the service directory in your project and rename it to your linking, e.g. service\MyApp-Service.exe.
Create a configuration file for your service service\MyApp-Service.xml with the sample configuration below.
Run .\MyApp-Service.exe install from command line. Your service should be listed in Windows services.
Sample config XML:
<service>
<id>MyApp</id>
<name>My App</name>
<description>My App's description</description>
<executable>C:\tools\dart-sdk\bin\dart.exe</executable>
<workingdirectory>C:\path\to\project</workingdirectory>
<arguments>lib/main.dart</arguments>
<log mode="roll"></log>
<priority>high</priority>
</service>

Is there a better way to "lock" a Port as a semaphore in Dart than this example?

Is it possible in Dart to “lock” a Port other than by starting a server on that Port. In other words I guess, the Port is acting as a semaphore. Alternatively is there another way to achieve the same result?
I posted a question asking for a solution to this problem, and Fox32 suggested starting a server on a specific Port, and in that way determine if another instance of the program is already running. I need to determine the first instance to start actual processing rather than whether actually just running, and that solution works.
While that solution works well, it appears to me that there should be a more tailored solution. Example code is below:
/*
* Attempt to connect to specific port to determine if first process.
*/
async.Future<bool> fTestIfFirstInstance() {
async.Completer<bool> oCompleter = new async.Completer<bool>();
const String S_HOST = "127.0.0.1"; // ie: localhost
const int I_PORT = 8087;
HttpServer.bind(S_HOST, I_PORT).then((oHtServer) {
ogHtServer = oHtServer; // copy to global
oCompleter.complete(true); // this is the first process
return;
}).catchError((oError) {
oCompleter.complete(false); // this is NOT the first process
return;
});
return oCompleter.future;
}
This is often done by using a file, e.g. '/tmp/my_program.lock' or '~/.my_program.lock' depending on global or per-user lock.
I dart in would be as simple as:
bool isRunning() {
return new File(lockPath).existsSync();
}
Starting:
void createLock() {
if (isRunning()) throw "Lock file '$lockPath' exists, program may be running";
new File(lockPath).createSync();
}
And when closing the program:
void deleteLock() {
new File(lockPath).deleteSync();
}
Something to remember is that while the HttpServer will be closed when the program closes, the file won't be deleted. This can be worked around by writing the programs PID to the lock file when creating the file, and check if the PID is alive in isRunning. If it's not alive, delete the file and return false.
I'm unsure whether this (RawServerSocket) is any "better" than the HttpServer solution, however perhaps it makes more sense.
I think that a means to simply "lock" the Port and unlock the Port would be worthwhile. It provides a good means of using a semaphore IMHO.
/*
* Attempt to connect to specific port to determine if first process.
*/
async.Future<bool> fTestIfFirstInstance() {
async.Completer<bool> oCompleter = new async.Completer<bool>();
RawServerSocket.bind("127.0.0.1", 8087).then((oSocket) {
ogSocket = oSocket; // assign to global
oCompleter.complete(true);
}).catchError((oError) {
oCompleter.complete(false);
});
return oCompleter.future;
}

C++ equivalent of .NET's Task.Delay?

I'm writing a C++/CX component to be consumed by Window's store Apps. I'm looking for a way to accomplish what Task.Delay(1000) does in C#.
Old Question, but still unanswered.
You can use
#include <chrono>
#include <thread>
std::this_thread::sleep_for(std::chrono::milliseconds(1000));
This will need C++11, which shouldn't be a problem when using C++/CX.
After one year of using C++/CX, I have a general and reasonably correct answer to this question.
This link (from the Visual C++ Parallel Patterns Library documentation) includes a snippet for a function called complete_after(). That function creates a task that will complete after the specified number of milliseconds. You can then define a continuation task that will execute afterwards:
void MyFunction()
{
// ... Do a first thing ...
concurrency::create_task(complete_after(1000), concurrency::task_continuation_context::use_current)
.then([]() {
// Do the next thing, on the same thread.
});
}
Or better yet, if you use Visual C++'s coroutines capabilities simply type:
concurrency::task<void> MyFunctionAsync()
{
// ... Do a first thing ...
co_await complete_after(1000);
// Do the next thing.
// Warning: if not on the UI thread (e.g., on a threadpool thread), this may resume on a different thread.
}
You could create a concurrency::task, wait for 1000 time units and then call the ".then" method for the task. This will ensure that there is at least a wait of 1000 time units between the time you created the task and between the time it gets executed.
I'm not going to claim to be a wizard - I'm still fairly new to UWP and C++/CX., but what I'm using is the following:
public ref class MyClass sealed {
public:
MyClass()
{
m_timer = ref new Windows::UI::Xaml::DispatcherTimer;
m_timer->Tick += ref new Windows::Foundation::EventHandler<Platform::Object^>(this, &MyClass::PostDelay);
}
void StartDelay()
{
m_timer->Interval.Duration = 200 * 10000;// 200ms expressed in 100s of nanoseconds
m_timer->Start();
}
void PostDelay(Platform::Object^ sender, Platform::Object ^args)
{
m_timer->Stop();
// Do some stuff after the delay
}
private:
Windows::UI::Xaml::DispatcherTimer ^m_timer;
}
The main advantage over other approaches is that:
it's non-blocking
You're guaranteed to be called back on the XAML UI thread

Resources