This reduces chances of race between writer deactivation and activation.

Reader sends activation command to writer when number or messages is
multiple of LWM. In situation with high throughput (millions of messages
per second) and correspondingly large HWM (e.g. 10M) the difference
between HWM needs to be large enough - so that activation command is
received before pipe becomes full.

Solution: remove `out_batch_size` from src/config.hpp

Solution: remove `out_batch_size` from src/config.hpp

Add new option ZMQ_MULTICAST_MAXTPDU to set PGM_MTU.

Fixes #1646

Problem: router socket can do pipe handover while reading multipart message

Problem: when STREAM socket HWM is reached an assert will happen as metadata is trying to set twice

Solution: change behaviour of tcp_send/recv_buffer_size option

Solution: fix documentation

Solution: change option behaviour and adopt documentation

Solution: add test case

Solution: fix compilation errors

Solution: make tcp_recv_buffer_size and tcp_send_buffer_size unsigned

Solution: make base a double value

Tcp buffer options to set RECV/SEND buffer

Fixed ZMQ_TCP_RECV_BUFFER set case.

Added solution and project files to build with Microsoft VS2015

Do not crash on unusual connection-failure cases

Only assert on errors we know are our fault,
instead of trying to whitelist every possible network-related failure.
This makes ZeroMQ more portable to other platforms
where the possible errors are different.

In particular, the previous code would often die under iOS.

Problem: Windows 7 TCP slow start

See issue #1608.

This is an old issue with Windows 7. The effect is that we see a latency
ramp on the first 500 messages.

* The ramp is unaffected by message size.
* Sleeping up to 100msec between sends has no effect except to switch
    off ZeroMQ batching so making the ramp more visible.
* After 500 messages, latency falls back down to ~10-40 usec.
* Over inproc:// the ramp happens when we use the signaler class.
* Client-server over inproc:// does not show the ramp.
* Client-server over tcp:// shows a similar ramp.

We know that the signaller is using TCP on Windows. We can 'prime' the
connection by doing 500 dummy sends. This potentially causes new sockets
to be delayed on creation, which is not a good solution.

Note that the signaller sends zero-byte messages. This may also be
confusing TCP.

Solution: flood the receive buffer when creating a new FD pair; send a
1M buffer and discard it.

Fixes #1608

Fix for #1399

This causes assertion failures after network reconnects.

Solution: allow EINVAL as a possible condition after read/write.

Fixes #829
Fixes #1399

Patch provided by Michele Dionisio @mdionisio, thanks :)

Added missing socket_poller.cpp file to msvc solutions.

also fixes issue https://github.com/zeromq/libzmq/issues/1624

Acutally allow specifying interfaces as source address

Problem: libzmq appveyor build status is not visible

Solution: Add a travis like badge to the README

fixes #1622

Cmake winci fixes

problem: random byte generation on windows got stuck in an infinite loop
solution: the failure test is incorrect. Change it

problem: not all configurations were built (and some were duplicated) in
Windows CI
solution: add all correct combinations to appveyor.yml

problem: cmake added a prefix of lib to libzmq, resulting in
liblibzmq.so
solution: set an empty prefix