One of the most important points of wsServer is its ease of use, so I'm happy that I've been able to keep up with the goal.

It bothers me a lot that other libraries require large chunks of code for a simple 'echo'.

It bothers me a lot that other libraries require large chunks of code for a simple 'echo'.

I can't agree it any more ! Besides, your code is elegant and comments-friendly.🍭

Thanks =)

I built and have tested with your example on an Intel Phi card

An Intel Xeon Phi card? Wow, that's very unexpected, but also awesome 😊

In example, how would you code as echo web socket server?

Well, I believe the example file already does that for you... for each message that a client sends, the example will display it on the screen and also send it to all connected clients.

How does this differ from your use case?

Just a thought:
WSS servicing possibly multiple client collections, derived collections, overrides for how to handle base client functions.
Clients collection, clients, client_add, client_remove. clients_active, clients_with_attribute, clients_broadcast, ... Thread and/or process safe add/remove locking one client. Clients like a group and client like a user. Perhaps returning a list ignoring any lock failures if inconsequential.

In my opinion the locking of the client list does not really solve the race condition behind.
Because any client connection may break even when/while the the list locked.
The lock just prevents an update of the list, isn't it?

Yes, you're completely right...

Assuming the ws_sendframe_txt(ws_client, "message"); in the list iteration loop fails
the clientlist requires an update to reflect new state?

If the client list is a copy of the original/internal, yes, if it's the same, no, not required.

a onclose() callback may occur?

Yes... an on_close() call can occur at any time. Unless you are inside an event, as each callback reflects a client thread, you will not receive a new callback (for that client) unless you return from the previous callback; but nothing prevents the server from calling callbacks from other clients... What I meant is that a thread inside an event/callback will not be interrupted by another event, since each event runs inside its own thread that corresponds to a client.

The side effect of this is that while inside an event for a given client, the server is unable to handle new messages and events from that client, until it returns from the current event. I think the main loop makes this clear.

Maybe I should make this clear in the docs: long processing or infinite loops inside an event is a big 'no no'. For this, the user can dispatch new threads or stack the new messages (for further processing) in some data structure.

In my mind, the provided client list should be intended to reflect the most recent known state, which means it can change at any time.
This helps the application programm to know if there were clients registered, and If a client is not marked as disconnected, it's worth to give communication a try (otherwise need to wait for an onopen() callback or recheck after a while).

I totally agree with you, which is why I'm scratching my head thinking of some viable way to do this. So you suggest sharing the internal list of clients directly, right? because it's the only way I think it's possible to maintain the current state of each client as things change.

Thus I feel you should not return from API back to application while any pending locks.

I think I know what you're saying, but I'm not sure... the server is always getting new connections, firing events and etc, so I'm not quite sure how to "return from API back to application while any pending locks".

What I can think of, is to protect each access to the client list (and also to a particular client) with a global lock (or not), so ws_sendframe* will not be able to send a message to a specific 'client_t', while that same client is being changed at the same time on the server.

Working with index makes iteration a snap ... for(int i=0; i < maxclients; i++){ ... }
One compromise approach may be to allocate a list with a fixed number of clients, but the number of list items is made selectable.
E.g. you allocate initially a list with size MAX_CLIENTS, and offer an new API function ws_realloc_client_list(int maxclients) which may be optionally used for advanced demands.

Of course, a linked list is the more sophisticated state of the art :-)
And iteration is also quite simple with while(ws_client_con_ptr->next != NULL){ ... }.
Benefit is that MAX_CLIENTS is no longer existent.

Maybe it's better (i.e., simpler) to keep a fixed list of clients: my initial thought of removing it was to avoid the loops that find the client's internal structure from fd (like the get_client_index() method does)... but by adopting a 'client_conn_t' this is solved.

A linked list makes it more complicated to share the current clients list since the list (and the ->next pointers) can be changed at any time.

About the 'MAX_CLIENTS' resizing, it's a good idea. Maybe I'll consider adding this in the future when these other issues are addressed.

I agree with your 'insecure feeling' when sharing the internal client list.
Can this mitigated a bit by declaring the pointed to items from outside API as const types?

One thing that came to my mind was using 'opaque types' (in ws.h), so the user is unable to see what's inside the structure and access it directly, which makes things like client[idx]->something impossible. Any useful access to client data I can provide via some API. So I think this sounds better to me than using const or something...

Or will this fool the C compiler optimizer in a way that the application does not always see the last recent update.
(Just thinking of volatile declared variables when they are modified by interrupt routines.)

Volatile and const together sounds contradictory to me... I'd rather hide implementation details than try to block/prevent access.

Hi @troglobytor, thanks for joining the discussion,

WSS servicing possibly multiple client collections, derived collections, overrides for how to handle base client functions.
Clients collection, clients, client_add, client_remove. clients_active, clients_with_attribute, clients_broadcast, ... Thread and/or process safe add/remove locking one client. Clients like a group and client like a user. Perhaps returning a list ignoring any lock failures if inconsequential.

I don't know if I understand exactly what you mean, but at the moment I just want to provide some easy way to iterate over the clients and maybe retrieve information about them through some routines in the API.

What you propose seems to be a bit out of scope for wsServer at the moment.

Sorry, sometimes I get too excited. Does some attribute change while compiling the list and does it matter if it does change? For those that don't matter then almost any method would suffice, but if it does, then an immediate action rather than continue building the list would reduce but not completely eliminate a change of attribute action error.

Before things are getting too complex and sophisticated ... I would like to come back to my initial challenge / use case.
This is already solved with the indend change of ws_sendframe_txt(ws_client_conn_t *client, const char *message) where broadcasting takes place with NULL as client parameter.
In my distinct use case, there is no longer a need for a client list (as I only like to broadcast, I do not care about the clients ...).
The request for a client list was brought up by me, because a valid file descriptor is required by current version.

Now I ask myself about any other use cases where a client list may be helpful ...

• Iterating over the list and talk to all clients - better done with a broadcast
• Counting the number of connected clients - easy done with incrementing/decrementing a counter by onopen() / onclose()
• Special cases where I need to maintain individual application level states per client - need anyway application code triggered by onXXX() callbacks and probably a dedicated client list managed by the application itself.

I cannot immediately sketch a use case for a generic client list, which is worth the efforts and considerations around (but there may be several ones).
So I have to withdraw my feature request :-)

@Theldus I guess you have already some use case in mind ... ?

If it's hard to find a use case, you may like to stick to your slogan (design goal ?) "Why to complicate if things can be simple?"

One thing that came to my mind was using 'opaque types' (in ws.h), so the user is unable to see what's inside the structure and access it directly, which makes things like client[idx]->something impossible. Any useful access to client data I can provide via some API. So I think this sounds better to me than using const or something...

Yes the client pointer may be seen as just some abstract pointer to a client (without any further info behind), just an API reference?
Then you are free on what you like to return with some ws_client_info(client *) function.
I could even imagine that the client pointer must not be used in any other way, than as a parameter to certain API functions. This gives API an option to check whether the given pointer is valid etc.
If the application tries to access pointers in already free()'d allocated memory, strange things may occur which are hard to find ...

Or will this fool the C compiler optimizer in a way that the application does not always see the last recent update.
(Just thinking of volatile declared variables when they are modified by interrupt routines.)

Volatile and const together sounds contradictory to me... I'd rather hide implementation details than try to block/prevent access.

You are right, that was also my concern ...

I would like to emphasize again that I like wsServer most because its simple to use, and I was really surprised how easy it was to implement websocket communication in my small project.

Sorry, sometimes I get too excited. Does some attribute change while compiling the list and does it matter if it does change? For those that don't matter then almost any method would suffice, but if it does, then an immediate action rather than continue building the list would reduce but not completely eliminate a change of attribute action error.

@troglobytor No worries =). Do you say the attributes of the client itself? they may change if I create/allocate a new list, but they remain fixed (or better said, updated) if I share the internal list of clients.

This is already solved with the indend change of ws_sendframe_txt(ws_client_conn_t *client, const char *message) where broadcasting takes place with NULL as client parameter.
In my distinct use case, there is no longer a need for a client list (as I only like to broadcast, I do not care about the clients ...).

@tinkering4fun Yes... you're right... I thought a client list was needed because this was already asked in issue #34 (although a broadcast without knowing a user beforehand would also solve the issue back then).

Now I ask myself about any other use cases where a client list may be helpful ...

Iterating over the list and talk to all clients - better done with a broadcast

Yes...

Counting the number of connected clients - easy done with incrementing/decrementing a counter by onopen() / onclose()

Also yes, although it requires some care for the increment/decrement to be atomic (multiples on_open()/on_close() can occur simultaneously).

Special cases where I need to maintain individual application level states per client - need anyway application code triggered by onXXX() callbacks and probably a dedicated client list managed by the application itself.

Also yes, like a websocket chat room I just saw here. I also need to reinforce the care that the addition/removal of clients in the list must be atomic as well.

@Theldus I guess you have already some use case in mind ... ?
If it's hard to find a use case, you may like to stick to your slogan (design goal ?) "Why to complicate if things can be simple?"

I don't exactly have an example at hand. I believe that most cases can be managed by the user himself, by maintaining a list of clients through on_open()/on_close() events.

And I think you've convinced me... most cases can be worked outside the library.

I think I just need to provide other example files addressing these cases so that the user experience is smoother with the library. I'm also planning to write a friendly markdown of documentation, explaining some use cases and so on.

I would like to emphasize again that I like wsServer most because its simple to use, and I was really surprised how easy it was to implement websocket communication in my small project.

Thank you. A few years ago when I needed a C library to write a small WebSocket server, all the ones I found seemed very complicated, with a lot of code for very little.

C doesn't have to be complicated, and that's what motivated me to write this library.

@tinkering4fun and @troglobytor huge thanks for the feedback, it helped me a lot to clarify things and direct me where I should work next in wsServer.

I will start working on the points discussed here:

• 'ws_client_t' instead of fd
• ws_sendframe* broadcast field will be removed

and in the future:

• markdown docs, friendly explaining how to use wsServer and etc
• more example files

and I'll let you know as soon as they're on the master. Again, thank you very much =).

Hi @domsson,

Thank you for your work on wsServer

You're welcome =)

My use-case seems very similar to that of @tinkering4fun - I want to have the server regularly push data to connected clients

And since you were interested, here is a bit more detail: I'm working on a minimalist set of tools that will enable the monitoring of multiple machines in a simple dashboard. For that, I want to have one WebSocket server running on each machine, which accepts a connection from the machine running the dashboard. I would then push updates to the dashboard whenever any of the vitals have changed. The fact that wsServer is written in C, its simplicity, easy setup and the lack of dependencies is what makes it a great fit for me, as some of those machines have very low specs and I can't afford to install much on them.

Looks like an interesting use case. I'm always curious about what people use this project for, so I'm glad to see it being used in the wild like this. @tinkering4fun's issue is now resolved, so I hope you don't run into the same problems as him.

Don't hesitate to create an issue or discussion if you have any questions about wsServer =).

Hi @NathanMani, thanks for giving wsServer a try,

built wsServer using GCC and run echo server on Linux machine.

ok

toyws client built using emsdk and converted to JS - "emcc tws_test.c toyws.c -o test.js" , nodejs used to run client

Why are you doing this? I mean, you can compile and use toyws by simply replacing 'emcc' with gcc/clang/etc like:

$ gcc tws_test.c toyws.c -o test
$ ./test

I believe you basically have three options:

• a) Since you are using Node, you certainly already have native support or there is some famous WebSocket client library (like this one) for Node.js, use it.

• b) If you want to use ToyWS as a Node.js library, you need to compile it as a Node.js module and then import it. Since toyws.c is quite simple this shouldn't be that complicated, but I still recommend the first option. Compiling a C code for WebAssembly and using it directly in Node as a library sounds like the wrong way to do it.

• c) Do not use Node at all: since ToyWS can work standalone, I can't see the applicability of using it together with Node.

Thank you for your kind words =).

Hi @pb-now,
Thanks.

Now days is quite impossible find library that doesn't depends from libraries, that depends from libraries, ...

I know that feeling, and so I've put a lot of effort into making wsServer simple enough to work out-of-the-box in a variety of environments, no extra deps or anything, just build it and start using it =).

Unfortunately it's not perfect, and some things annoys me, like: use of threads (some systems don't have threads, like Minix), (ab)use of mutexes I don't like either, code a little messy in some places... but I plan to address that some day...

Hi @cyberbilly,
Thanks for giving wsServer a try,

Execution returns to the ubuntu prompt in about a second. No error message a sub optimal operation.

When running the echo example, it should keep running indefinitely... can you see the return value? like:

$ ./examples/echo/echo
$ echo $?
0

If you are having a segfault or something like that, you can try to enable core dump and view it with GDB to inspect the stack trace, and etc...

The only clue I have is the system log contains the following:
Jan 10 09:56:07 potato wpa_supplicant[370]: wlx3c3300306567: CTRL-EVENT-BEACON-LOSS

This doesn't seem related to wsServer, but rather to your WiFi, from a quick Google search: [Solved] Unstable Wifi connection

Hi @cyberbilly,

I really don't know what's going on... it wasn't supposed to return immediately, and even if it did, it should have at least printed some error message.

I need more information about the execution flow to have any idea, please apply this patch and build wsServer as follows:

$ git clone https://github.com/Theldus/wsServer
$ cd wsServer/
$ wget https://gist.githubusercontent.com/Theldus/8fe6827ff6db21d331da72384da42334/raw/f71cec777c0ecaab2ce64879aa6d3eed4f891d4d/backtrace.diff
$ patch -p1 < backtrace.diff 
patching file src/ws.c
$ mkdir build
$ cd build
$ CFLAGS="-finstrument-functions" LDFLAGS="-rdynamic" cmake .. -DCMAKE_BUILD_TYPE=Debug
$ make

and then run the example echo file, which should then display all invoked functions:

$ ./examples/echo/echo 
 >./examples/echo/echo(main+0) [0x4024ec]
 >./examples/echo/echo(ws_socket+0) [0x404f24]
 >./examples/echo/echo(do_bind_socket+0) [0x404d70]
 <./examples/echo/echo(do_bind_socket+0) [0x404d70]
Waiting for incoming connections...
 >./examples/echo/echo(ws_accept+0) [0x404945]

I'm assuming that your environment supports GCC/Clang and uses glibc as well, otherwise the above procedure will not work.

Please let me know if you were able to apply and build wsServer with this patch and your output, I'm very curious about it...

Hi @keygee,
Thanks for giving wsServer a try.
I think your approach is good, it makes sense to me, from what I understand.

I wouldn't worry too much about having the best approach right from the start, but about being correct: if you can receive these status updates and send them correctly to the clients, the rest you can worry about later ;-).