If you are interested in benchmarks of G-WAN, see [1].
To run a benchmark yourself, see [2].
609 karma · joined October 28, 2011
https://www.ers35.com/
To run a benchmark yourself, see [2].
The CAPTCHA example has two parts: generating the CAPTCHA values and presenting them in a way that is easy for humans to solve, but difficult for computers.
This example only implements part one, but gives some methods of how one could implement part two. This is why it is so easy for you to write a script to solve it.
Using mouse cursor hovering, one could change the background color behind the image based on an event (such as a mouseover of an input field) that is probable for a human to make, but less so for a computer. This is difficult for a computer to solve, but not impossible to break.
G-WAN applications are persistent, meaning it is trivial to record stateless actions the client has made in the past for use in the future. The client would have to provide a known good value from the past in order to solve the CAPTCHA. This is what is meant by "previous state or shared secret".
That example is easy to solve because it is not using any of the provided techniques that makes it more difficult for robots to solve the CAPTCHA: "changing the HTML background color based on: mouse cursor hovering, previous state or input or shared secret"
The purpose of the example is to give you a basis on which you could implement an effective CAPTCHA.
The claim of "difficult or even completely impossible for robots" applies to CAPTCHAs using the above techniques, which are not used in the example.
The purpose of the example is to give you a basis on which you could implement an effective CAPTCHA.
The claim of "difficult or even completely impossible for robots" applies to CAPTCHAs using the above techniques, which are not used in the example.
See page 2 of http://gwan.ch/archives/g-wan_case.pdf.
As for the second, I agree that the source of those "units sold" should be cited.
JavaScript, Lua, and Python can be linked directly with the server for performance you would not get via separate processes.
I had more difficulty with Go, which you can read about on the forum.[1]
They all work, but are just proofs of concept at the moment. G-WAN makes it easy to link with any C library, so it is not hard to use languages that expose a C API such as those listed. It is just a matter of writing a more complete handler.
[1]http://forum.gwan.com/index.php?p=/discussion/463/writing-g-...
* G-WAN is not open-source, so people (justifiably) resist trying it.
* It lacks software that takes advantage of the platform.
* G-WAN gets limited coverage on news sites. (it's banned from Wikipedia for example)
* People react negatively to the extraordinary claims made by its author without verifying them with the provided benchmark toolWhat word do you suggest I use to describe configuring a program to have access to more sockets?
> Even moreso than the whole "hey, run it as root, broseph!" part.
In daemon mode, G-WAN drops privileges to the user and group of your choosing.
See [1] for reasons why PHP+FastCGI is a poor choice in 2012.
Remove sudo and the examples still work.
* A small, yet useful set of core APIs (http://gwan.ch/api)
* Applications are recompiled on the fly when a change is made
* A "no compromises" attitude to performance and software design
* It supports legacy applications written in CGI-style without the cost of CGI
G-WAN is not merely a "hello world" server. See [2] for the API features and [3] for more details.
[1]http://nbonvin.wordpress.com/2011/03/24/serving-small-static...
Perhaps these forum threads will help.[1][2]
[1]http://forum.gwan.com/index.php?p=/discussion/393/how-to-dis...
[2]http://forum.gwan.com/index.php?p=/discussion/comment/5812/
I have tested the claims and find them to be legitimate.
If you have a more specific question, I may be able to provide more details.
That is no longer accurate. G-WAN now supports C, Java, C++, D, and Objective C out of the box. [1] I am the someone who is implementing FastCGI support.
[1]http://nbonvin.wordpress.com/2011/03/24/serving-small-static...
Doesn't the example below show otherwise? Note the presence of movdqu in both memcopy_normal and memcopy_restrict and how GCC emits five LEA instructions without restrict, but only two when restrict is present.
This does not support the author's assertion that "Aliasing information is the only one, where I am certain about speed improvements, because it is impossible to reach Fortran-speed in C."
#include "stddef.h"
void* memcopy_normal(void* dst, const void* src, size_t count) {
while (count--) *(char*)dst++ = *(char*)src++;
return dst;
}
void* memcopy_restrict(void* restrict dst, const void* restrict src, size_t count) {
while (count--) *(char* restrict)dst++ = *(char* restrict)src++;
return dst;
}
> gcc -S -masm=intel -std=c99 -m64 -march=corei7 -O3 restrict2.c
.file "restrict2.c"
.intel_syntax noprefix
.text
.p2align 4,,15
.globl memcopy_normal
.type memcopy_normal, @function
memcopy_normal:
.LFB0:
.cfi_startproc
test rdx, rdx
mov rax, rdi
je .L2
lea r10, [rdx-1]
mov r8, rdx
shr r8, 4
mov r9, r8
sal r9, 4
test r9, r9
je .L7
lea rcx, [rsi+16]
cmp rdx, 15
lea r11, [rax+16]
seta dil
cmp rax, rcx
seta cl
cmp rsi, r11
seta r11b
or ecx, r11d
test dil, cl
je .L7
xor ecx, ecx
xor edi, edi
.p2align 4,,10
.p2align 3
.L4:
movdqu xmm0, XMMWORD PTR [rsi+rcx]
add rdi, 1
movdqu XMMWORD PTR [rax+rcx], xmm0
add rcx, 16
cmp r8, rdi
ja .L4
lea r8, [rax+r9]
add rsi, r9
sub r10, r9
cmp rdx, r9
je .L5
.L3:
lea r9, [r10+1]
xor ecx, ecx
.p2align 4,,10
.p2align 3
.L6:
movzx edi, BYTE PTR [rsi+rcx]
mov BYTE PTR [r8+rcx], dil
add rcx, 1
cmp r9, rcx
jne .L6
.L5:
add rax, rdx
.L2:
rep
ret
.L7:
mov r8, rax
jmp .L3
.cfi_endproc
.LFE0:
.size memcopy_normal, .-memcopy_normal
.p2align 4,,15
.globl memcopy_restrict
.type memcopy_restrict, @function
memcopy_restrict:
.LFB1:
.cfi_startproc
push r12
.cfi_def_cfa_offset 16
.cfi_offset 12, -16
test rdx, rdx
mov rax, rdi
push rbp
.cfi_def_cfa_offset 24
.cfi_offset 6, -24
push rbx
.cfi_def_cfa_offset 32
.cfi_offset 3, -32
je .L12
lea r10, [rdx-1]
mov r11, rsi
mov r8, rsi
neg r11
and r11d, 15
cmp r11, rdx
cmova r11, rdx
test r11, r11
je .L13
xor ecx, ecx
.p2align 4,,10
.p2align 3
.L14:
movzx r9d, BYTE PTR [r8]
add rcx, 1
add r8, 1
sub r10, 1
mov BYTE PTR [rdi], r9b
add rdi, 1
cmp r11, rcx
ja .L14
cmp rdx, r11
je .L15
.L13:
mov r12, rdx
sub r12, r11
mov rbx, r12
shr rbx, 4
mov rbp, rbx
sal rbp, 4
test rbp, rbp
je .L16
add rsi, r11
xor ecx, ecx
add r11, rax
xor r9d, r9d
.p2align 4,,10
.p2align 3
.L17:
movdqa xmm0, XMMWORD PTR [rsi+rcx]
add r9, 1
movdqu XMMWORD PTR [r11+rcx], xmm0
add rcx, 16
cmp rbx, r9
ja .L17
add rdi, rbp
add r8, rbp
sub r10, rbp
cmp r12, rbp
je .L15
.L16:
lea r9, [r10+1]
xor ecx, ecx
.p2align 4,,10
.p2align 3
.L18:
movzx esi, BYTE PTR [r8+rcx]
mov BYTE PTR [rdi+rcx], sil
add rcx, 1
cmp r9, rcx
jne .L18
.L15:
add rax, rdx
.L12:
pop rbx
.cfi_def_cfa_offset 24
pop rbp
.cfi_def_cfa_offset 16
pop r12
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1:
.size memcopy_restrict, .-memcopy_restrict
.ident "GCC: (GNU) 4.6.3"
.section .note.GNU-stack,"",@progbitsI have logged out of my account since I do not want to cause any harm. Please fix.
Do you have another example of him spamming a mailing list?