Okay, so then my suggestion would be ~2^16 bytes as maximum value, but a
default value of 8191 bytes or lower. Plus the option to change the
value, in order to make libzmq applicable in local network applications
that use larger UDP messages (e.g. a team of service robots cooperating
in your household). Further an API level error message or assert, that
shortly explains the issue when sending UDP messages, larger than the
value set.
Thoughts?
On 12.01.20 23:04, Greg Young wrote:
If not clear ... if you are on a network *you control* is very
different than being on one you do not.
On Sun, Jan 12, 2020 at 5:02 PM Greg Young <[email protected]
<mailto:[email protected]>> wrote:
This is correct ... Some things may not accept/forward it.
Beyond that its common for things to get *added to it* thus you
want to be below. Consider a case where its being wrapped
(tunneling is a good example).
Over the internet the maximum completely safe size is even smaller
around 500-600 bytes :O You can usually get above this but +- 1k
is about the limit.
On Sun, Jan 12, 2020 at 4:42 PM Stephan Opfer
<[email protected] <mailto:[email protected]>> wrote:
Ah okay. I read some posts about MTU and fragmentation. So in
theory 2^16= 65536 Bytes should be possible, but not all
nodes will accept such large UDP packets and support the
fragmentation of it?
FYI: My use case is that of a local network (IOT + Autonomous
Robots) and increasing the size would help me. :)
On 12.01.20 13:25, Doron Somech wrote:
We can increase it to around 65,000 bytes, however, large UDP
packets would probably be dropped when traveling outside your
local area network.
The safe size for the UDP packet to travel outside of the
local area network is around 500 bytes.
If you do want to use large UDP packets on your local area
network you might want to increase the network MTU (jumbo
frames) for better delivery.
For example, some AWS instances support 9001 bytes MTU for
inter-instance communication.
On Fri, Jan 10, 2020 at 3:25 PM Stephan Opfer
<[email protected] <mailto:[email protected]>> wrote:
Hi all,
since 2016 there is this issue
(https://github.com/zeromq/libzmq/issues/2009) about some
limitations of
the udp_engine in libzmq.
Is it possible that someone at least will increase the
"#define
MAX_UDP_MSG 8192" in libzmq/src/udp_engine.hpp to some
reasonable value?
For example "ZMQ_MAX_MSGSZ" from the zmq context option,
which is MAX_INT.
Maybe, someone could spare some time at the Hackathon... ;-)
Greetings,
Stephan
--
Distributed Systems Research Group
Stephan Opfer T. +49 561 804-6279 F. +49 561 804-6277
Univ. Kassel, FB 16, Wilhelmshöher Allee 73, D-34121 Kassel
WWW: http://www.uni-kassel.de/go/vs_stephan-opfer/
_______________________________________________
zeromq-dev mailing list
[email protected]
<mailto:[email protected]>
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
--
Distributed Systems Research Group
Stephan Opfer T. +49 561 804-6279 F. +49 561 804-6277
Univ. Kassel, FB 16, Wilhelmshöher Allee 73, D-34121 Kassel
WWW:http://www.uni-kassel.de/go/vs_stephan-opfer/
_______________________________________________
zeromq-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
--
Studying for the Turing test
--
Studying for the Turing test
_______________________________________________
zeromq-dev mailing list
[email protected]
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
--
Distributed Systems Research Group
Stephan Opfer T. +49 561 804-6279 F. +49 561 804-6277
Univ. Kassel, FB 16, Wilhelmshöher Allee 73, D-34121 Kassel
WWW: http://www.uni-kassel.de/go/vs_stephan-opfer/
_______________________________________________
zeromq-dev mailing list
[email protected]
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
