Tutorial Ideas

[Peter Thorson]

Hi all,

I am working on some tutorials for WebSocket++ and was wondering if anyone here has specific features or concepts that they feel would be particularly useful to have covered? Anything that you wish there was a tutorial for now or wished there had been when you were first setting up your WebSocket++ application?

Best,

Peter

[Michael Chadwick]

I'm brand-new to WebSocket++, and what I really want to be able to do is pass data back and forth, preferably JSON style data.

I had to make some tweaks to the C++ syntax in the WebSocket++ header files to get an empty app to compile while including the WebSocket++ headers. I'm using Embarcadero Builder XE4 with Boost libraries, so I'm guessing it was just my compiler being persnickety.

Anyway, I am working through the user manual and examples right now, hoping I can figure it out before a tutorial is released.

[Peter Thorson]

Hi Michael,

Thanks for the feedback, regarding the compiler errors and tweaks you had to make, I'd love to see a list of those compiler errors to see if any of the fixes you made can be incorporated into the library itself.

Peter

--
You received this message because you are subscribed to the Google Groups "WebSocket++" group.
To unsubscribe from this group and stop receiving emails from it, send an email to websocketpp...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Michael Chadwick]

Hmm, I'll share some of the changes I had to make and let you evaluate them. Some of them may not have been necessary; maybe you can point me to a better way in some or all of these cases.

• In some of the function typedefs (maybe all of them that had a const parameter), I moved the const to the beginning of the parameter.
  Example:
  typedef lib::function<void(lib::error_code const &,size_t)> read_handler;
  becomes
  typedef lib::function<void(const lib::error_code &,size_t)> read_handler;
  
• Some of the function typedefs that had more than one parameter wouldn't compile for some reason, so for each one I created a new class on the fly that had the needed parameters as members. I'm not sure if this is good coding practice, but I wasn't sure what other workaround to use. I was just trying to get my empty app to compile while including the headers--I'm sure I'll discover some other calls where the parameters haven't been switched.
  Example:
  typedef lib::function<bool(connection_hdl,std::string)> ping_handler;
  becomes
  typedef lib::function<bool(connection_hdl_w_string)> ping_handler;
  where connection_hdl_w_string is defined:
  class connection_hdl_w_string
  {
  public:
  connection_hdl con;
  std::string str;
  };
• I replaced all the #include <websocket\*.hpp>s with #include "*.hpp"s. I also added the websocketpp folder to my include and lib paths, else I would have had to keep websocketpp\ on the first part of the. This change might not have been strictly necessary, but in all my other projects with this IDE, that's the syntax we use for local files, and I wasn't sure how else to get the IDE to find the files.
  Example:
  #include <websocketpp/roles/client_endpoint.hpp>
  becomes
  #include "roles/client_endpoint.hpp"
  
• Wherever handler objects were created, I added parameter lists. Builder was really confused at function objects (that are typedefed with parameters) being instantiated without parameters.
  Example:
      open_handler            m_open_handler;
      close_handler           m_close_handler;
      fail_handler            m_fail_handler;
      ping_handler            m_ping_handler;
      pong_handler            m_pong_handler;
      pong_timeout_handler    m_pong_timeout_handler;
      interrupt_handler       m_interrupt_handler;
      etc.
  becomes
  open_handler            m_open_handler(connection_hdl con);
          close_handler           m_close_handler(connection_hdl con);
  fail_handler            m_fail_handler(connection_hdl con);
  ping_handler            m_ping_handler(connection_hdl_w_string con_w_str);
  pong_handler            m_pong_handler(connection_hdl_w_string con_w_str);
  pong_timeout_handler    m_pong_timeout_handler(connection_hdl_w_string con_w_str);
  interrupt_handler       m_interrupt_handler(connection_hdl con);
          etc.

I might have made a few other tweaks, but I think those were most of them. Like I said, they were mostly syntax changes.

Hope that helps.

[Tony]

I would say: messaging and memory allocation/buffer copy concerns when sending and receiving messages.
However, you said you are going to work on different strategies in that department, so it is probably too early to cover that now. 

I see that as an important topic for apps that may be exchanging big or smaller but bursty messages.

[Tony]

Precise steps - code changes to enable/disable logging at various levels, both compile time and run time. Details on what level logs what. What do I get if I include headers with "debug" word in them, as opposed to those without.

On Tuesday, October 8, 2013 9:31:23 AM UTC-4, Peter Thorson wrote:

[hact]

I'd second Michael's suggestion. It'd be nice to have a tutorial cover 2-way communication between a server and a client, maybe even a minimal example for interaction with a html5 web page.

Thanks,
Till

[jimbo...@gmail.com]

Once you showed me how to setup on ubuntu, and I looked through all of the examples, I found everything I needed.

I think pointing to the ubuntu setup wiki page and providing a list with descriptions of the examples on github, zaphoyd.com, and this group's description would be perfect for a c++ noob such as myself.

[Michael Chadwick]

I discovered today that the 32-bit version of my compiler (which is what I was using) is not C++11 compliant (it only goes up to C++0x) so that may have had something to do with the issues I was having compiling. When I come back to this project I might try it in the 64-bit compiler and see if C++11 makes a difference.

[jimbo...@gmail.com]

For simple communication, there's plenty of examples online.

You can test your server with this client code http://www.tutorialspoint.com/html5/html5_websocket.htm

and this server example https://github.com/zaphoyd/websocketpp/blob/master/examples/broadcast_server/broadcast_server.cpp

Just change the client code's port to 9002 or the server code's port to 9888.

[jimbo...@gmail.com]

For json, I use json-spirit.  It's very easy to setup & use, and even better it is boost based, so it fits right in.

To receive, you can do something like this:

using namespace json_spirit;

...


if(receivedMessage.content->get_opcode() == websocketpp::frame::opcode::text){

 mValue value;
 if(read(receivedMessage.content->get_payload(), value))
...

It's very sweet that it won't throw an error if the message is not json.  read() will simply return false.  However, there is nothing similar (yet?) as far as I know when trying to read types, so if you try to manipulate the wrong type, it will throw.

For sending, you can do something like this:

Object jsonResult;
jsonResult.push_back( Pair( "testKey", "testValue") );

for (it = m_connections.begin(); it != m_connections.end(); ++it) {
 m_server.send(*it, write(jsonResult), websocketpp::frame::opcode::text);
}

The for() is based upon the broadcast_server.  

I've heard some complain about performance, so I'll start a discussion...

[jimbo...@gmail.com]

Peter,

Thank you endlessly for making it so that c++ noobs can have high performance servers with little to no work!  I have setup friends with a few play servers and possibly one or two serious ones in no time all thanks to your incredible library.

I haven't looked at the tutorials because aside from a few special tweaks here and there, I haven't had need to deviate from broadcast_server's general structure.

Based upon what I've been seeing on stack lately, it looks like your lib is attracting a veritable c++ noob army because people instantly see the genius of your code.  As a noob who has recently graduated to novice, I can relate, and I don't think it takes much to get the library going to its fullest extent, codewise.

I think that an overblown, complete example is probably all that we need to get going.  To that end, I recommend a peer to peer broadcast server with both secured & unsecured client & server endpoints, tcp_no_delay disabled, major handlers configured, and singular functions for close and send, all properly error_coded.

If you don't mind, I'll try to learn git, write up a comprehensive example, and try to commit, if that helps.  I'm really just copying & pasting the same broadcast_server template with the special features and debugging you've shown me over the years.

Thank you so much for this library, zaphoyd!  I truly think you're opening so many doors for modern web development!

[Fry 李]

In my opinion, the demo should have these features:

(1) how to get the client ip addr?

(2) how to build a server with single thread to accept many clients?

(3) how to build a message? ( I spent an afternoon to master the method)

(4) how does the server deal with client shutdown message when the client is shutdown without sending closing message to the server?

(5) how to validate the client? (how to use the validation method)

(6) how to build a simple distributed server? (in advance)

[Wei Yang]

Hi, Peter,

I believe this is a sophisticated websocket implementation, if I have one suggestion, I would like to see some documentation on the software architecture.

For example, some chart on the module relationships like below

The relationship between connection/endpoint and their parent.

Or the relationship between those config

Maybe this would help the audience to understand the architecture of websocketpp.

On Tuesday, October 8, 2013 at 9:31:23 PM UTC+8, Peter Thorson wrote:

[胡乐秋]

How to write a websocketpp client over a serial port? my transmission process is: serial port => dtu(SIM card) => websocketpp  server. 

[Jacky Wei]

 为 serial port 写一个守护进程就可以了，守护进程与websocket 交互，dtu Sim card只是提供网络通路的。 

On Mon, Jan 7, 2019 at 9:28 AM 胡乐秋 <hul...@gmail.com> wrote:

How to write a websocketpp client over a serial port? my transmission process is: serial port => dtu(SIM card) => websocketpp  server. 

--

You received this message because you are subscribed to the Google Groups "WebSocket++" group.
To unsubscribe from this group and stop receiving emails from it, send an email to websocketpp...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Tom William]

Dear sir,

could you give me the link of your tutorial because I am new and I need it to learn how to use this library in my project?

best regards