sque/liboonet

liboonet's Issues

Create documentation for library

Documentation must include rich doxygen comments that can be used to extract a nice API reference, a manual on how library works with many many examples.

[TEST]StringConverter fails on linux

___StringConverter_(7_tests)________+_Test_+_CPU__+_Exception_________________
   1| Ctor() default... Size of wchar_t 4
| ok | 0 |
   2| toUnicode (English)... | ok | 0 |
   3| toUnicode (Greek)... | FAIL | 0 |
    >> - (0)

   4| toUnicode (French)... | FAIL | 0 |
    >> - (0)

   5| toAnsi from (English)... | ok | 0 |
   6| toAnsi from (Greek)... | ok | 0 |
   7| toAnsi from (French)... | ok | 0 |

Enhance and stabilize binary_data interface

binary_data is the heart of liboonet, so we must take more care, although it is the best code inside liboonet. Some things must be revised and the interface must be stabilized.

• scale_mem() It works... but we haven't investigate if it could do it better
• operator[] It works... but it does a VERY expensive test for buffer over/under flow. We must follow std::vector specification operator[] does not do range check, at() does range check.
• Implement binary_data to follow "ForwardContainer" concept. (Compatibility with stdlib)
• Drop various constructors and leave only one from cmem_ref.
• Cast to string() It is helpfull but there aren't only std::string in this world, so we must either provide ALL or nothing. [^1]
• Investigate if we are taking full advantage of CoW.
• Use the new mem_ref interface for reacting with external memory objects
• Investigate if we can implement Concat On Read

[1] Still under discussion

Memory block

We need to implement an abstract base class for all arbitrary data container objects called "memory_block".

Approach A:

• We cannot use built "const" of C++ on memory_block because it easy to have by accident privileged escalation.
  It is better approach to have memory_block and const_memory_block as iterators do it.
  A memory_block can be given wherever a const_memory_block is requested.
• We need to create a connector or reference of memory_blocks with already allocated memory. like a variable

Approach B

• Use built-in const but dont allow copy and copy constructable of ABC memory_block

Approach C

• Create a templated STL "Container" compliant type named array_ref and create two type definitions mem_ref (byte) and cmem_ref (const byte)
  • array_ref should be able to bind on any C array.
  • array_ref must behave as an array except A = B must copy reference
  • array_ref is a specialized version with a alias typedef "mem_ref" and can be constructed from a "MemoryContainer" concept
  • array_ref is a specialized version with a alias typedef "cmem_ref" and can be constructed from a "ContMemoryContainer" concept

RawMemoryContainer
members:
- byte * raw_ptr(size_t offset);
- size * raw_size() const;

ConstRawMemoryContainer

• inherit MemoryContainer
• const byte * raw_ptr(size_t offset) const;

Maximize throughput

We need to maximize throughput of the library. To archieve this we must:

• Sockets with zero-copy on receive and send.
• Use only real references, reduce copy by value at minimum, and reference copy.
• Parsing must be one way. Reparsing areas is expensive.

Proposed implementation

Sockets:

• Uncopiable with API open() close() opened()
• dont use reference count
• zero-copy send() and receive()

http::response creates header "Content-Length" with zero data

Creating an http::response with zero size body will add header "Content-Length: 0" which it should be omitted.

Code review must be done for socket_address etc classes

The socket_address breaks some fundamental programming principals. For example it is virtual but has copy constructor and operator. This class does something really simple, it should be rewritten in a more proper way as it will not break anything else.