1
0
Fork 0
mirror of https://github.com/warmcat/libwebsockets.git synced 2025-03-09 00:00:04 +01:00

reduce log spew and document test-server variants

This commit is contained in:
Andy Green 2016-06-30 10:11:59 +08:00
parent 8fdff1053c
commit f25eefdd41
10 changed files with 111 additions and 17 deletions

View file

@ -1,3 +1,49 @@
Overview of lws test apps
=========================
Are you building a client? You just need to look at the test client
[libwebsockets-test-client](test-server/test-client.c).
If you are building a standalone server, there are three choices, in order of
preferability.
1) lwsws + protocol plugins
Lws provides a generic web server app that can be configured with JSON
config files. https://libwebsockets.org itself uses this method.
With lwsws handling the serving part, you only need to write an lws protocol
plugin. See [plugin-standalone](plugin-standalone) for an example of how
to do that outside lws itself, using lws public apis.
$ cmake .. -DLWS_WITH_LWSWS=1
See [README.lwsws.md](README.lwsws.md) for information on how to configure
lwsws.
NOTE this method implies libuv is used by lws, to provide crossplatform
implementations of timers, dynamic lib loading etc for plugins and lwsws.
2) test-server-v2.0.c
This method lets you configure web serving in code, instead of using lwsws.
Plugins are still used, which implies libuv needed.
$ cmake .. -DLWS_WITH_PLUGINS=1
See [test-server-v2.0.c](test-server/test-server-v2.0.c)
3) protocols in the server app
This is the original way lws implemented servers, plugins and libuv are not
required, but without plugins separating the protocol code directly, the
combined code is all squidged together and is much less maintainable.
This method is still supported in lws but all ongoing and future work is
being done in protocol plugins only.
Notes about lws test apps
=========================

File diff suppressed because one or more lines are too long

View file

@ -4,7 +4,7 @@
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.8.11"/>
<title>libwebsockets: Notes about lws test apps</title>
<title>libwebsockets: Overview of lws test apps</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
@ -62,10 +62,27 @@ $(document).ready(function(){initNavTree('md_README.test-apps.html','');});
<div id="doc-content">
<div class="header">
<div class="headertitle">
<div class="title">Notes about lws test apps </div> </div>
<div class="title">Overview of lws test apps </div> </div>
</div><!--header-->
<div class="contents">
<div class="textblock"><h2>Testing server with a browser </h2>
<div class="textblock"><p>Are you building a client? You just need to look at the test client <a href="test-server/test-client.c">libwebsockets-test-client</a>.</p>
<p>If you are building a standalone server, there are three choices, in order of preferability.</p>
<p>1) lwsws + protocol plugins</p>
<p>Lws provides a generic web server app that can be configured with JSON config files. <a href="https://libwebsockets.org">https://libwebsockets.org</a> itself uses this method.</p>
<p>With lwsws handling the serving part, you only need to write an lws protocol plugin. See [plugin-standalone](plugin-standalone) for an example of how to do that outside lws itself, using lws public apis.</p>
<p>$ cmake .. -DLWS_WITH_LWSWS=1</p>
<p>See <a class="el" href="md_README.lwsws.html">README.lwsws.md</a> for information on how to configure lwsws.</p>
<p>NOTE this method implies libuv is used by lws, to provide crossplatform implementations of timers, dynamic lib loading etc for plugins and lwsws.</p>
<p>2) test-server-v2.0.c</p>
<p>This method lets you configure web serving in code, instead of using lwsws.</p>
<p>Plugins are still used, which implies libuv needed.</p>
<p>$ cmake .. -DLWS_WITH_PLUGINS=1</p>
<p>See <a href="test-server/test-server-v2.0.c">test-server-v2.0.c</a></p>
<p>3) protocols in the server app</p>
<p>This is the original way lws implemented servers, plugins and libuv are not required, but without plugins separating the protocol code directly, the combined code is all squidged together and is much less maintainable.</p>
<p>This method is still supported in lws but all ongoing and future work is being done in protocol plugins only.</p>
<h1>Notes about lws test apps </h1>
<h2>Testing server with a browser </h2>
<p>If you run <a href="test-server/test-server.c">libwebsockets-test-server</a> and point your browser (eg, Chrome) to </p><pre class="fragment"> http://127.0.0.1:7681
</pre><p>It will fetch a script in the form of <code>test.html</code>, and then run the script in there on the browser to open a websocket connection. Incrementing numbers should appear in the browser display.</p>
<p>By default the test server logs to both stderr and syslog, you can control what is logged using <code>-d &lt;log level&gt;</code>, see later.</p>

View file

@ -6,7 +6,7 @@ var NAVTREE =
[ "Notes about lwsws", "md_README.lwsws.html", null ],
[ "Notes about coding with lws", "md_README.coding.html", null ],
[ "Notes about generic-sessions Plugin", "md_README.generic-sessions.html", null ],
[ "Notes about lws test apps", "md_README.test-apps.html", null ],
[ "Overview of lws test apps", "md_README.test-apps.html", null ],
[ "Deprecated List", "deprecated.html", null ],
[ "Modules", "modules.html", "modules" ],
[ "Data Structures", "annotated.html", [

View file

@ -71,7 +71,7 @@ $(document).ready(function(){initNavTree('pages.html','');});
<tr id="row_1_"><td class="entry"><span style="width:16px;display:inline-block;">&#160;</span><a class="el" href="md_README.lwsws.html" target="_self">Notes about lwsws</a></td><td class="desc"></td></tr>
<tr id="row_2_" class="even"><td class="entry"><span style="width:16px;display:inline-block;">&#160;</span><a class="el" href="md_README.coding.html" target="_self">Notes about coding with lws</a></td><td class="desc"></td></tr>
<tr id="row_3_"><td class="entry"><span style="width:16px;display:inline-block;">&#160;</span><a class="el" href="md_README.generic-sessions.html" target="_self">Notes about generic-sessions Plugin</a></td><td class="desc"></td></tr>
<tr id="row_4_" class="even"><td class="entry"><span style="width:16px;display:inline-block;">&#160;</span><a class="el" href="md_README.test-apps.html" target="_self">Notes about lws test apps</a></td><td class="desc"></td></tr>
<tr id="row_4_" class="even"><td class="entry"><span style="width:16px;display:inline-block;">&#160;</span><a class="el" href="md_README.test-apps.html" target="_self">Overview of lws test apps</a></td><td class="desc"></td></tr>
<tr id="row_5_"><td class="entry"><span style="width:16px;display:inline-block;">&#160;</span><a class="el" href="deprecated.html" target="_self">Deprecated List</a></td><td class="desc"></td></tr>
</table>
</div><!-- directory -->

View file

@ -1,3 +1,37 @@
Are you building a client? You just need to look at the test client \href{test-server/test-client.c}{\tt libwebsockets-\/test-\/client}.
If you are building a standalone server, there are three choices, in order of preferability.
1) lwsws + protocol plugins
Lws provides a generic web server app that can be configured with J\+S\+ON config files. \href{https://libwebsockets.org}{\tt https\+://libwebsockets.\+org} itself uses this method.
With lwsws handling the serving part, you only need to write an lws protocol plugin. See \mbox{[}plugin-\/standalone\mbox{]}(plugin-\/standalone) for an example of how to do that outside lws itself, using lws public apis.
\$ cmake .. -\/\+D\+L\+W\+S\+\_\+\+W\+I\+T\+H\+\_\+\+L\+W\+S\+WS=1
See \hyperlink{md_README.lwsws}{R\+E\+A\+D\+ME.lwsws.md} for information on how to configure lwsws.
N\+O\+TE this method implies libuv is used by lws, to provide crossplatform implementations of timers, dynamic lib loading etc for plugins and lwsws.
2) test-\/server-\/v2.\+0.\+c
This method lets you configure web serving in code, instead of using lwsws.
Plugins are still used, which implies libuv needed.
\$ cmake .. -\/\+D\+L\+W\+S\+\_\+\+W\+I\+T\+H\+\_\+\+P\+L\+U\+G\+I\+NS=1
See \href{test-server/test-server-v2.0.c}{\tt test-\/server-\/v2.\+0.\+c}
3) protocols in the server app
This is the original way lws implemented servers, plugins and libuv are not required, but without plugins separating the protocol code directly, the combined code is all squidged together and is much less maintainable.
This method is still supported in lws but all ongoing and future work is being done in protocol plugins only.
\section*{Notes about lws test apps }
\subsection*{Testing server with a browser }
If you run \href{test-server/test-server.c}{\tt libwebsockets-\/test-\/server} and point your browser (eg, Chrome) to \begin{DoxyVerb} http://127.0.0.1:7681

View file

@ -155,7 +155,7 @@
\label{md_README.generic-sessions}
\hypertarget{md_README.generic-sessions}{}
\input{md_README.generic-sessions}
\chapter{Notes about lws test apps}
\chapter{Overview of lws test apps}
\label{md_README.test-apps}
\hypertarget{md_README.test-apps}{}
\input{md_README.test-apps}

View file

@ -870,7 +870,7 @@ lws_http_action(struct lws *wsi)
} else {
/* deferred cleanup and reset to protocols[0] */
lwsl_notice("no hit\n");
lwsl_info("no hit\n");
if (lws_bind_protocol(wsi, &wsi->vhost->protocols[0]))
return 1;
@ -1853,7 +1853,7 @@ lws_serve_http_file(struct lws *wsi, const char *file, const char *content_type,
O_RDONLY);
if (wsi->u.http.fd == LWS_INVALID_FILE) {
lwsl_err("Unable to open '%s'\n", file);
lwsl_info("Unable to open '%s'\n", file);
lws_return_http_status(wsi, HTTP_STATUS_NOT_FOUND, NULL);
return -1;

View file

@ -209,7 +209,7 @@ int callback_http(struct lws *wsi, enum lws_callback_reasons reason, void *user,
switch (reason) {
case LWS_CALLBACK_HTTP:
lwsl_notice("lws_http_serve: %s\n",in);
lwsl_info("lws_http_serve: %s\n",in);
if (debug_level & LLL_INFO) {
dump_handshake_info(wsi);
@ -223,11 +223,8 @@ int callback_http(struct lws *wsi, enum lws_callback_reasons reason, void *user,
}
{
char name[100], rip[50];
lws_get_peer_addresses(wsi, lws_get_socket_fd(wsi), name,
sizeof(name), rip, sizeof(rip));
sprintf(buf, "%s (%s)", name, rip);
lwsl_notice("HTTP connect from %s\n", buf);
lws_get_peer_simple(wsi, buf, sizeof(buf));
lwsl_info("HTTP connect from %s\n", buf);
}
if (len < 1) {
@ -497,7 +494,7 @@ int callback_http(struct lws *wsi, enum lws_callback_reasons reason, void *user,
return 1;
goto try_to_reuse;
case LWS_CALLBACK_HTTP_DROP_PROTOCOL:
lwsl_notice("LWS_CALLBACK_HTTP_DROP_PROTOCOL\n");
lwsl_debug("LWS_CALLBACK_HTTP_DROP_PROTOCOL\n");
/* called when our wsi user_space is going to be destroyed */
if (pss->spa) {

View file

@ -135,7 +135,7 @@ test_server_fops_open(struct lws *wsi, const char *filename,
/* call through to original platform implementation */
n = fops_plat.open(wsi, filename, filelen, flags);
lwsl_notice("%s: opening %s, ret %ld, len %lu\n", __func__, filename,
lwsl_info("%s: opening %s, ret %ld, len %lu\n", __func__, filename,
(long)n, *filelen);
return n;