added more c apis and capi ssl version with capi examples #1395

cirospaciari · 2022-01-05T00:48:15Z

This adds a complete useful capi with ssl suport and most examples added.

It's a step to solve this issue: #1192
Opaque C interface for Swift, Rust, etc

For now its just a wrapper and can be optimized a lot, but its a start.

make capi, and make capi_examples for build added

… added Async example with abort handler, added var in Makefile for capi library

cirospaciari · 2022-01-06T14:33:52Z

instead of uws_app_listen(SSL, style i wrote in uws_ssl_... style because responses and websockets has diferent types while in App and SSLApp, with a constant with -O3 optimization and a static library i think the code will be generated ok and inlined, but i want to use this capi in Ruby with FFI and i dont want to have a if to check pointer conversions at runtime>

In dynamic typed languages as Ruby, Python and Lua, UWS::App and UWS::SSLApp will be easy to implement and switch between App and SSLApp and static typed languages with generics is easy too to create variants (like in rust)

In pure C with different structs when matters, keep me/developers safe to make mistakes like passing a ssl version of response in uws_res_end instead of uws_ssl_res_end without overhead, if someone wants to use the capi in C instead of integrate with a dynamic library in other language, and don't want to write different codes to switch between App and SSLApp, a header with macros would solve this problem in a safe way.

I tested with autocannon -c 100 -d 40 -p 10 http://localhost:3000/ and the CAPIHelloWorld and HelloWorld produces the same/similar performance numbers, Ruby integrates very well currently i'm testing with FFI and i will integrate with Python and Rust with FFI too, source code available in my github (just for linux for now, will be cross platform solution later)

ghost · 2022-01-07T02:59:06Z

I like the energy but there are a few problems -

I've fixed the existing experimental CAPI and it now works with identical performance as the C++ one so the idea is very much valid.

Problems:

You add copies and dynamic memory allocations everywhere via that toNullTerminated - that's a big no no
SSL should be an argument, we don't want the whole API duplicated for every protocol, esp. not when QUIC is yet another protocol
Benchmarking with autocannon is 10000000% invalid. Use uSockets/http_load_test. Performance MUST BE IDENTICAL as C++, there can be NO DIFFERENCE AT ALL, or the whole thing must be thrown in the garbage.
Dynamic linking with .so is a big no no, must be a static library built with LTO optimization otherwise performance goes to shit.
You don't need to make tons of examples, the important is getting the library itself done.
I like the name libuwebsockets.so, but it should be libuwebsockets.a

It is extremely important that perf. remains identical to the original (this is the case with existing experiment).

cirospaciari · 2022-01-07T16:24:06Z

Yea the toNullTerminated was a mistake for sure but is easy replaceable.
I created the examples while developing and using the C++ examples as a reference, so I include them.

About the performance testing i will look on http_load_test, i used autocannon and wrk for http because it's the tools I knew, if you can tell me the reasons why using autocannon would be invalid I would be grateful (so I don't make that mistake again).

I will take a look in the last commit you made in the current experiment, and will change the SSL version to be a parameter.

I will remove the toNulllTermined and improve to get the same performance in the C wrapper.

CAPI (my version)
./http_load_test 40 localhost 3000
Running benchmark now...
Req/sec: 299293.000000
Req/sec: 285187.250000
Req/sec: 298784.750000
Req/sec: 297208.500000
Req/sec: 299072.500000
Req/sec: 291401.000000
^C
C++ original version:
./http_load_test 40 localhost 3000
Running benchmark now...
Req/sec: 328924.500000
Req/sec: 330413.000000
Req/sec: 332356.750000
Req/sec: 332048.000000
Req/sec: 331578.500000

Its clear the performance hit when using http_load_test, i will stick with http_load_test for now and the future.

ghost · 2022-01-07T17:30:53Z

I want to test with the SSL as argument in my experiment to check one extra time it remains the same perf.

Also another thing:

You don't need to wrap libusockets - that library is already C, so just leave it be. You see that libusockets use SSL as first argument so libuwebsockets should as well.

ghost · 2022-01-07T17:32:33Z

I also want to make a very basic minimal test of a Rust wrapper with a nice interface much like the one in C++ to see if that is even viable - if so then it could make sense to create a Rust crate that just works out of the box. And maybe even a Swift one - then the reach of the project can expand without being limited by scripting performance loss.

cirospaciari · 2022-01-07T19:01:56Z

I want to test with the SSL as argument in my experiment to check one extra time it remains the same perf.

Also another thing:

You don't need to wrap libusockets - that library is already C, so just leave it be. You see that libusockets use SSL as first argument so libuwebsockets should as well.

I tested with the SSL parameter and the performance numbers are the same, after and before.
I tested in rust too and i have some little variation but i think its margin of error because the difference its not consistent a more complex sample testing maybe highlight something, but for now seems good.

#define SSL 1

void get_handler(uws_res_t *res, uws_req_t *req) {
    uws_res_end(SSL, res, "Hello CAPI!", 11);
}

void listen_handler(void *listen_socket) {
    if (listen_socket) {
        printf("Listening on port now\n");
    }
}

int main() {
    uws_app_t *app = uws_create_app(SSL, (struct us_socket_context_options_t){
        /* There are example certificates in uWebSockets.js repo */
	    .key_file_name = "../misc/key.pem",
	    .cert_file_name = "../misc/cert.pem",
	    .passphrase = "1234"
    });
    uws_app_get(SSL, app, "/*", get_handler);
    uws_app_listen(SSL, app, 3000, listen_handler);
    uws_app_run(SSL, app);
}

ghost · 2022-01-07T19:25:52Z

Yeah as long as it is a static library compiled with LTO it should constant fold that if statement

cirospaciari · 2022-01-07T23:34:11Z

I added length in all points that i needed pass a string_view and it bring the performance up tothe same as the C++ version.

I also add some changes in example.rs now examples/RustHelloWorld.rs, now i able to compile on my machine without warnings and errors.

I removed all copies and dynamic memory allocations, but i'm trying to get the reader for do a upgrade (i want to make it work in C and add to Rust for testing) in my last commit UpgradeSync/UpgradeAsync

The header will never returns because its a std::string_view, i'm trying something like this:

const char *uws_req_get_header(uws_req_t *res, const char *lower_case_header, size_t lower_case_header_length)
{
      uWS::HttpRequest *uwsReq = (uWS::HttpRequest *)res;
      std::string_view header = uwsReq->getHeader(std::string_view(lower_case_header, lower_case_header_length));
      return std::string(header).c_str();
}

and the call in UpgradeSync.c:

const char* header= uws_req_get_header(request, "sec-websocket-extensions", 24);

The string_view will get out of scope and free, how can i accomplish this or with strategy i should use to get the headers without dynamic alloc or copy? i could pass a buffer and a buffer size and copy the info back, but i want help to know if exists a better alternative.

After this i will add the SSL params in all points.

ghost · 2022-01-08T00:38:19Z

I'm playing with something like this:

fn main() {
    App::new().get(|res, req| {
        //res.end("Hello world!");
    }).listen(|listenSocket| {
        if listenSocket != 0.0 {
            println!("Listening now!");
        }
    }).run();
}

cirospaciari · 2022-01-08T00:41:04Z

I'm playing with something like this:

fn main() {
    App::new().get(|res, req| {
        //res.end("Hello world!");
    }).listen(|listenSocket| {
        if listenSocket != 0.0 {
            println!("Listening now!");
        }
    }).run();
}

Cool very close to my ruby version

UWS::App.new()
.get("/", lambda {|response, request| response.end("Hello World uWS from Ruby!")})
.listen(8082, lambda {|socket, config| puts "Listening on port #{config.port}" })
.run()

cirospaciari · 2022-01-08T11:27:26Z

Performance impacts before are from char* to string_view convertions without length and the use of dynamic library it self (about of 13% of performance impact), now perfoms the same

CAPI

cirospaciari@gl702vsk:~/Desktop/teste/uWebSockets/uSockets$  ./http_load_test 40 localhost 3000
Running benchmark now...
Req/sec: 318886.250000
Req/sec: 321785.750000
Req/sec: 320193.250000
Req/sec: 313785.750000
^C

C++

cirospaciari@gl702vsk:~/Desktop/teste/uWebSockets/uSockets$ ./http_load_test 40 localhost 3000
Running benchmark now...
Req/sec: 313398.750000
Req/sec: 312036.750000
Req/sec: 317940.750000
Req/sec: 320571.250000
^C

I will add the SSL parameters now and add a more complex sample using Uprade and Broadcast with Rust and i will collect some performance data and compare Rust, CAPI and C++. I think if we static link we should have zero or almost zero performance impact with a more OOP like Rust wrapper, i will do a stress test and measuring if in some place the compiler will not fold the conditional (i belive if we create a crate with the wrapper maybe the compiler will not optimize but lets do some testing)

cirospaciari · 2022-01-08T13:25:54Z

Without heavy modifications i could archive the code bellow without performance impact:

extern "C" fn listen_handler(
    _listen_socket: *mut ::std::os::raw::c_void,
    config: UwsAppListenConfigT,
) {
    println!("Listening on port {}", config.port);
}

extern "C" fn get_handler(res: *mut UwsResT, _: *mut UwsReqT) {
    unsafe {
        let message = ::std::ffi::CString::new("Hello Rust!").expect("");
        uws_res_end(res, message.as_ptr(), 11, false);
    }
}


fn main() {
    App::new()
        .get("/", get_handler)
        .listen(3000, listen_handler)
        .run();
}

For archive what you expected in rust passing a user_data: void* is needed:

fn main() {
    App::new()
        .get("/", |res, _req| {
            res.end("Hello Rust!");
        })
        .listen(3000, |_listen_socket, config| {
            println!("Listening on port http://127.0.0.1:{}", config.port);
        })
        .run();
}

No visible performance loss:

CAPI

cirospaciari@gl702vsk:~/Desktop/teste/uWebSockets/uSockets$ ./http_load_test 40 localhost 3000
Running benchmark now...
Req/sec: 311942.000000
Req/sec: 319498.250000
Req/sec: 323747.000000
^C

Rust

cirospaciari@gl702vsk:~/Desktop/teste/uWebSockets/uSockets$ ./http_load_test 40 localhost 3000
Running benchmark now...
Req/sec: 319163.000000
Req/sec: 323562.500000
Req/sec: 323056.250000
^C

ghost · 2022-01-08T13:38:20Z

One thing missing is that all functions that take a function must also take a void pointer so closures can be set. That's a little tricky, I need to look at Rust pointers. If that works without perf loss then everything should be set

cirospaciari · 2022-01-08T13:39:50Z

One thing missing is that all functions that take a function must also take a void pointer so closures can be set. That's a little tricky, I need to look at Rust pointers. If that works without perf loss then everything should be set

I was typing just that haha, yeah is tricky but is useful in other languages too, i used this in "uws_create_timer" as a helper and in uws_res_on_aborted, uws_res_on_data and uws_res_on_writable

I will keep my branch updated

Edit: Added the void pointers, was i said before i cannot measure any performance loss with http_load_test, after a little break i will start working in the SSL parameter

the following is working in capi/examples/RustHelloWorld.rs
make default will create HelloWorld (capi) and RustHelloWorld
make rust will only create RustHelloWorld

fn main() {
    App::new()
        .get("/", |res, _req| {
            res.end("Hello Rust!");
        })
        .listen(3000, |_listen_socket, config| {
            println!("Listening on port http://127.0.0.1:{}", config.port);
        })
        .run();
}

mohan-win · 2022-10-28T12:25:04Z

@cirospaciari , Thanks for the awesome effort, wondering if you have any idea when this PR would get merged ?

cirospaciari · 2022-10-28T13:34:47Z

@cirospaciari , Thanks for the awesome effort, wondering if you have any idea when this PR would get merged ?

No idea I still working on this, today I will add more fixes, integrations, updates and push again.

You can follow my progress on my project cirospaciari/socketify.py#10

I hope until end of this year I get this fully working with HTTP3 too, I can just work few hours in a couple of months but I will get more effort until December

mohan-win · 2022-10-28T15:58:56Z

@cirospaciari , Thanks for the awesome effort, wondering if you have any idea when this PR would get merged ?

No idea I still working on this, today I will add more fixes, integrations, updates and push again.

You can follow my progress on my project cirospaciari/socketify.py#10

I hope until end of this year I get this fully working with HTTP3 too, I can just work few hours in a couple of months but I will get more effort until December

Got it, thanks...

uNetworkingAB · 2022-10-28T16:38:19Z

I need to figure out how this plays along with the c wrapper used by bun. Maybe the bun wrapper was built from this PR? Anyways one of the two are great additions

uNetworkingAB · 2022-10-28T16:42:27Z

https://github.com/oven-sh/bun/blob/0bfd00e734ebe6093fd69badbc1d733d039f3d6a/src/deps/libuwsockets.cpp

If you look there, does that look like a copy of this PR, or a completely separate wrapper?

cirospaciari · 2022-10-28T16:53:45Z

https://github.com/oven-sh/bun/blob/0bfd00e734ebe6093fd69badbc1d733d039f3d6a/src/deps/libuwsockets.cpp

If you look there, does that look like a copy of this PR, or a completely separate wrapper?

Looks a lot with my solution but have some differences, like using memcpy, my wrapper seems to be more feature complete, I will update with the last version and add more things today after my lunch break, I think maybe is a copy of my PR at some point but if is the case I will only be glad for helping Bun

…_header

uNetworkingAB · 2022-10-28T17:21:47Z

I also thought the bun one looked like your PR

cirospaciari · 2022-10-28T17:26:21Z

I need to figure out how this plays along with the c wrapper used by bun. Maybe the bun wrapper was built from this PR? Anyways one of the two are great additions

I opened an discussion on Bun offering help to add more features, i think we can use this PR as an official C wrapper in future and converge Bun.sh to use the same version. This weekend i will add Http3 Support.
I was already using in some projects this wrapper and is doing great.

EDIT:
@uNetworkingAB
Jarred responded and it's a copy of this PR but with some additions like i thought (oven-sh/bun#1414) I will contribute to Bun and keeping contributing with this wrapper, so we can converge in one solution.

…ples

…paciari/uWebSockets into capi-complete-with-ssl-and-samples

…p_domain, and option to pass nullptr to http routes for dynamically removes

uNetworkingAB · 2022-10-29T01:59:12Z

Great, could you remove all changes that aren't related to capi folder. This PR should really only (initially at least) add a new folder.

…safe

cirospaciari · 2022-10-29T02:24:14Z

Great, could you remove all changes that aren't related to capi folder. This PR should really only (initially at least) add a new folder.

Sure i will remove all changes that are not in capi folder, but i thinking in expose cork and uncork but i could do it in another fork.

cirospaciari · 2022-10-29T02:44:25Z

@uNetworkingAB reverted any changes outside capi folder, sorry for the mess.

uNetworkingAB · 2022-10-29T02:50:33Z

Very kickass. Feel free to make a new PR from master with further changes

added more apis and ssl version with most examples

918c4f3

cirospaciari changed the title ~~added more apis and ssl version with most examples~~ added more capis and capi ssl version with most examples Jan 5, 2022

cirospaciari changed the title ~~added more capis and capi ssl version with most examples~~ added more c apis and capi ssl version with capi examples Jan 5, 2022

cirospaciari added 3 commits January 5, 2022 17:43

some make files ajusts

b07115a

set close connection to false (7~10x better performance) in examples,…

1d1f32c

… added Async example with abort handler, added var in Makefile for capi library

added better comments and fixed CAPIHelloWorldASync sample

fa0e01b

cirospaciari added 2 commits January 7, 2022 14:43

removed ssl and removed allocations

c9f9984

added make file

237fbdd

cirospaciari added 3 commits January 7, 2022 20:20

removed dynamic allocations

64473a5

add rust example and rename other samples

67bc8eb

merge with updated commits in master

525c97d

cirospaciari added 2 commits January 7, 2022 20:55

remove make capi and make capi_examples from the main Makefile

4720253

remove capi targets from clean on main Makefile

28b57af

add buffer solution for get header and some string_view values

70bd698

added more Rust like sample

55a17d4

add void* user_data in all places with handlers

7ecc637

uNetworking deleted a comment from Prozi Oct 11, 2022

cirospaciari added 2 commits October 24, 2022 13:35

cork tests

a17089a

updated with master

39d96d2

cirospaciari added 2 commits October 28, 2022 14:15

added uws_req_get_full_url, uws_req_for_each_header, uws_req_for_each…

d516309

…_header

revert HttpResponse.h log changes

32e366d

cirospaciari added 5 commits October 28, 2022 17:52

Merge branch 'uNetworking:master' into capi-complete-with-ssl-and-sam…

1fdde5d

…ples

initial add for bun features (Thanks Jarred)

6fb8b45

Merge branch 'master' into capi-complete-with-ssl-and-samples

f9fc89b

Merge branch 'capi-complete-with-ssl-and-samples' of github.com:ciros…

a9a2484

…paciari/uWebSockets into capi-complete-with-ssl-and-samples

add uws_app_listen_domain, uws_app_listen_domain_with_options, uws_ap…

d635fa9

…p_domain, and option to pass nullptr to http routes for dynamically removes

added uws_res_state, HttpResponse and WebSocket corkUnsafe + uncorkUn…

3acc134

…safe

cirospaciari added 6 commits October 28, 2022 23:26

removing changes in HttpResponse and WebSocket

417871d

revert changes outside capi

25f8345

new lines at the end revert

4d7f45d

revert makefiles

f17a91a

revert makefiles last new line

12d1a19

revert makefiles last new line

d38dbd8

uNetworkingAB merged commit 3f72aea into uNetworking:master Oct 29, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

added more c apis and capi ssl version with capi examples #1395

added more c apis and capi ssl version with capi examples #1395

cirospaciari commented Jan 5, 2022 •

edited

Loading

cirospaciari commented Jan 6, 2022 •

edited

Loading

ghost commented Jan 7, 2022

cirospaciari commented Jan 7, 2022 •

edited

Loading

ghost commented Jan 7, 2022

ghost commented Jan 7, 2022

cirospaciari commented Jan 7, 2022

ghost commented Jan 7, 2022

cirospaciari commented Jan 7, 2022 •

edited

Loading

ghost commented Jan 8, 2022

cirospaciari commented Jan 8, 2022

cirospaciari commented Jan 8, 2022

cirospaciari commented Jan 8, 2022

ghost commented Jan 8, 2022

cirospaciari commented Jan 8, 2022 •

edited

Loading

mohan-win commented Oct 28, 2022

cirospaciari commented Oct 28, 2022 •

edited

Loading

mohan-win commented Oct 28, 2022

uNetworkingAB commented Oct 28, 2022

uNetworkingAB commented Oct 28, 2022

cirospaciari commented Oct 28, 2022 •

edited

Loading

uNetworkingAB commented Oct 28, 2022

cirospaciari commented Oct 28, 2022 •

edited

Loading

uNetworkingAB commented Oct 29, 2022

cirospaciari commented Oct 29, 2022

cirospaciari commented Oct 29, 2022

uNetworkingAB commented Oct 29, 2022

added more c apis and capi ssl version with capi examples #1395

added more c apis and capi ssl version with capi examples #1395

Conversation

cirospaciari commented Jan 5, 2022 • edited Loading

cirospaciari commented Jan 6, 2022 • edited Loading

ghost commented Jan 7, 2022

cirospaciari commented Jan 7, 2022 • edited Loading

ghost commented Jan 7, 2022

ghost commented Jan 7, 2022

cirospaciari commented Jan 7, 2022

ghost commented Jan 7, 2022

cirospaciari commented Jan 7, 2022 • edited Loading

ghost commented Jan 8, 2022

cirospaciari commented Jan 8, 2022

cirospaciari commented Jan 8, 2022

CAPI

C++

cirospaciari commented Jan 8, 2022

CAPI

Rust

ghost commented Jan 8, 2022

cirospaciari commented Jan 8, 2022 • edited Loading

mohan-win commented Oct 28, 2022

cirospaciari commented Oct 28, 2022 • edited Loading

mohan-win commented Oct 28, 2022

uNetworkingAB commented Oct 28, 2022

uNetworkingAB commented Oct 28, 2022

cirospaciari commented Oct 28, 2022 • edited Loading

uNetworkingAB commented Oct 28, 2022

cirospaciari commented Oct 28, 2022 • edited Loading

uNetworkingAB commented Oct 29, 2022

cirospaciari commented Oct 29, 2022

cirospaciari commented Oct 29, 2022

uNetworkingAB commented Oct 29, 2022

cirospaciari commented Jan 5, 2022 •

edited

Loading

cirospaciari commented Jan 6, 2022 •

edited

Loading

cirospaciari commented Jan 7, 2022 •

edited

Loading

cirospaciari commented Jan 7, 2022 •

edited

Loading

cirospaciari commented Jan 8, 2022 •

edited

Loading

cirospaciari commented Oct 28, 2022 •

edited

Loading

cirospaciari commented Oct 28, 2022 •

edited

Loading

cirospaciari commented Oct 28, 2022 •

edited

Loading