Andy Green | 6c1f64e | 2013-01-20 11:28:06 +0800 | [diff] [blame] | 1 | Daemonization |
| 2 | ------------- |
| 3 | |
| 4 | There's a helper api lws_daemonize built by default that does everything you |
| 5 | need to daemonize well, including creating a lock file. If you're making |
| 6 | what's basically a daemon, just call this early in your init to fork to a |
| 7 | headless background process and exit the starting process. |
| 8 | |
| 9 | Notice stdout, stderr, stdin are all redirected to /dev/null to enforce your |
| 10 | daemon is headless, so you'll need to sort out alternative logging, by, eg, |
| 11 | syslog. |
| 12 | |
| 13 | |
| 14 | Maximum number of connections |
| 15 | ----------------------------- |
| 16 | |
| 17 | The maximum number of connections the library can deal with is decided when |
| 18 | it starts by querying the OS to find out how many file descriptors it is |
| 19 | allowed to open (1024 on Fedora for example). It then allocates arrays that |
| 20 | allow up to that many connections, minus whatever other file descriptors are |
| 21 | in use by the user code. |
| 22 | |
| 23 | If you want to restrict that allocation, or increase it, you can use ulimit or |
| 24 | similar to change the avaiable number of file descriptors, and when restarted |
| 25 | libwebsockets will adapt accordingly. |
| 26 | |
| 27 | |
Andy Green | 52f28ce | 2013-01-25 17:34:15 +0800 | [diff] [blame] | 28 | Procedure for sending data from other threads or process contexts |
| 29 | ----------------------------------------------------------------- |
| 30 | |
| 31 | Libwebsockets is carefully designed to work with no blocking in a single thread. |
| 32 | In some cases where you will add libwebsockets to something else that uses the |
| 33 | same single thread approach, you can so a safe implementation by combining the |
| 34 | poll() loops as described in "External Polling loop support" below. |
| 35 | |
| 36 | In other cases, you find you have asynchronous events coming from other thread |
| 37 | or process contexts and there's not much you can do about it. If you just try |
| 38 | to randomly send, or broadcast using libwebsockets_broadcast() from these other |
| 39 | places things will blow up either quickly or when the events on the two threads |
| 40 | interefere with each other. It's not legal to do this. |
| 41 | |
| 42 | For those situations, you can use libwebsockets_broadcast_foreign(). This |
| 43 | serializes the data you're sending using a private, per-protocol socket, so the |
| 44 | service thread picks it up when it's ready, and it is serviced from the service |
| 45 | thread context only. |
| 46 | |
| 47 | |
Andy Green | 6c1f64e | 2013-01-20 11:28:06 +0800 | [diff] [blame] | 48 | Fragmented messages |
| 49 | ------------------- |
| 50 | |
| 51 | To support fragmented messages you need to check for the final |
| 52 | frame of a message with libwebsocket_is_final_fragment. This |
| 53 | check can be combined with libwebsockets_remaining_packet_payload |
| 54 | to gather the whole contents of a message, eg: |
| 55 | |
| 56 | case LWS_CALLBACK_RECEIVE: |
| 57 | { |
| 58 | Client * const client = (Client *)user; |
| 59 | const size_t remaining = libwebsockets_remaining_packet_payload(wsi); |
| 60 | |
| 61 | if (!remaining && libwebsocket_is_final_fragment(wsi)) { |
| 62 | if (client->HasFragments()) { |
| 63 | client->AppendMessageFragment(in, len, 0); |
| 64 | in = (void *)client->GetMessage(); |
| 65 | len = client->GetMessageLength(); |
| 66 | } |
| 67 | |
| 68 | client->ProcessMessage((char *)in, len, wsi); |
| 69 | client->ResetMessage(); |
| 70 | } else |
| 71 | client->AppendMessageFragment(in, len, remaining); |
| 72 | } |
| 73 | break; |
| 74 | |
| 75 | The test app llibwebsockets-test-fraggle sources also show how to |
| 76 | deal with fragmented messages. |
| 77 | |
Andy Green | 52f28ce | 2013-01-25 17:34:15 +0800 | [diff] [blame] | 78 | |
Andy Green | 6c1f64e | 2013-01-20 11:28:06 +0800 | [diff] [blame] | 79 | Debug Logging |
| 80 | ------------- |
| 81 | |
| 82 | Also using lws_set_log_level api you may provide a custom callback to actually |
| 83 | emit the log string. By default, this points to an internal emit function |
| 84 | that sends to stderr. Setting it to NULL leaves it as it is instead. |
| 85 | |
| 86 | A helper function lwsl_emit_syslog() is exported from the library to simplify |
| 87 | logging to syslog. You still need to use setlogmask, openlog and closelog |
| 88 | in your user code. |
| 89 | |
| 90 | The logging apis are made available for user code. |
| 91 | |
| 92 | lwsl_err(...) |
| 93 | lwsl_warn(...) |
| 94 | lwsl_notice(...) |
| 95 | lwsl_info(...) |
| 96 | lwsl_debug(...) |
| 97 | |
| 98 | The difference between notice and info is that notice will be logged by default |
| 99 | whereas info is ignored by default. |
| 100 | |
| 101 | |
| 102 | External Polling Loop support |
| 103 | ----------------------------- |
| 104 | |
| 105 | libwebsockets maintains an internal poll() array for all of its |
| 106 | sockets, but you can instead integrate the sockets into an |
| 107 | external polling array. That's needed if libwebsockets will |
| 108 | cooperate with an existing poll array maintained by another |
| 109 | server. |
| 110 | |
| 111 | Four callbacks LWS_CALLBACK_ADD_POLL_FD, LWS_CALLBACK_DEL_POLL_FD, |
| 112 | LWS_CALLBACK_SET_MODE_POLL_FD and LWS_CALLBACK_CLEAR_MODE_POLL_FD |
| 113 | appear in the callback for protocol 0 and allow interface code to |
| 114 | manage socket descriptors in other poll loops. |
| 115 | |
| 116 | |