I have a client, whose code I can't change -- but I'd like to (re)write using ZeroMQ sockets.
The clients use both raw TCP and raw UDP sockets.
I know I can use ZMQ_ROUTER_RAW for raw TCP sockets, but what about for raw UDP datastreams?
Support for UDP in ZeroMQ is brand new. The documentation for the new socket types (Radio/Dish) was just pushed to the GitHub repository a few days ago. As of right now, though, it still looks like there's no raw UDP support, but perhaps it will stem out of this new functionality.
I'd recommend commenting on the existing thread about adding UDP support: https://github.com/zeromq/libzmq/issues/807 .
UDP Support for ZMQ is now documented here:
http://api.zeromq.org/master:zmq-udp
Pyzmq version 18 has it as well, stating: "Protocols supported include tcp, udp, pgm, epgm, inproc and ipc." That said, my experimentation with Python hasn't found a solution that works yet. I get "protocol is not compatible with socket type" errors.
Related
Can someone point me to some documentation on how to implement a Bittorrent UDP application?
I am working on a Bittorrent application and I can successfully download using TCP but I want to implement UDP and I can't find any information on it. I am retrieving peers with UDP trackers but that approach appears different than downloading files.
If I sniff a UDP Handshake I see the following in Wireshark:
172.16.49.213 5.31.44.30 UDP 62 35507 → 18318 Len=20
5.31.44.30 172.16.49.213 UDP 62 18318 → 35507 Len=20
This is done before the handshake. Also, it looks like there are 20 bytes prepended to the Handshake (different than the 20 bytes above).
So I need some information to help me with what all this means.
The BitTorrent Peer Wire Protocol over UDP, called uTP is specified in:
BEP29 - uTorrent transport protocol
BitTorrentInc has also published uTP as a IETF RFC were they call it LEDBAT:
RFC 6817 - Low Extra Delay Background Transport (LEDBAT)
However, I wouldn't recommend anyone to do their own implementation, (except as a learning experience), as it involves a lot of time critical, low level network IO and is very tricky to get right.
Instead I recommend to use the library: https://github.com/bittorrent/libutp
Almost all clients implementing uTP uses this library. AFAIK, the only exception is libtorrent/rasterbar (used by qBittorrent and Deluge) and it don't work as good as libutp does.
I'm going to implement Java VoiP server to work with WebRtc. Implementation of browser p2p connection is really straightforward. Server to client connection is slightly more tricky.
After a quick look at RFC I wrote down what should be done to make Java server as browser. Kindly help me to complete list below.
Implement STUN server. Server should be abke to respond binding
request and keep-alive pings.
Implement DTLS protocol along with DTLS handshake. After the DTLS
handshake shared secret will be used as keying material within SRTP
and SRTCP.
Support multiplexing of SRTP and SRTCP stream. SRTP and SRTCP use
same port to adress NAT issue.
Not sure whether should I implement SRTCP. I believe connection will
not be broken, if server does not send SRTCP reports to client.
Decode SRTP stream to RTP.
Questions:
Is there anything else which should be done on server-side ?
How webRtc handles SRTCP reports ? Does it adjust sample rate/bit
rate depends on SRTCP report?
WebRtc claims that following issues will be addressed:
packet loss concealment
echo cancellation
bandwidth adaptivity
dynamic jitter buffering
automatic gain control
noise reduction and suppression
Is is webRtc internals or codec(Opus) internals? Do I need to do anything on server side to handle this issues, for example variable bitrate etc ?
The first step would be to implement Interactive Connectivity Establishement (RFC 5245). Whether you make use of a STUN/TURN server or not is irrelevant, your code needs to issue connectivity checks (which use STUN messages) to the browser and respond to the brower's connectivity checks. ICE is a fairly complex state machine, but it's doable.
You don't have to reinvent the wheel. STUN / TURN servers are external components. Use as they are. WebRTC source code is available which you can use in your application code and call the related methods.
Pls. refer to similar post - Server as WebRTC data channel peer
So I'm sort of lost and need some direction for research.
I want to build a real-time audio chat environment with as low latency as possible.
I've done a little research and it looks like I have to use the UDP over TCP protocol, but I'm unsure of how to do this.
If I had a dedicated server running lamp, would I run a separate application listen for and serve UDP packets?
Any direction woudl be appreciated.
The best way when it comes to audio or video is to always use the UDP protocol, this protocol does not provide error control, UDP is connectionless protocol that tells me that when you send a data over UDP you don't know if it'll get there, can occur corruption while transferring, to audio or video this can be a nice idea !
You can create dedicated server listening in UDP port to receive all data and pass to the corresponding client!
You need learn about socket programming, choose your preferred language and learn how use socket, this is the way.
What is the most simple and straightforward approach for serverless P2P UDP chat in Boost Asio? The chat will work across the internet. There are ready UDP examples but they all maintain client-server approach!
I'm assuming that by serverless you mean a P2P network without a central control server.
IMO your question has little to do with boost-asio. asio is a cross-platform network library. You seem to be asking more of a network engineering type question and asio is just one of the tools you can use for implementation.
The examples are client-server in that the example applications possibly fall under the client-server architecture. However the socket code (or asio usage) used to send and receive messages will look the same irrespective of client-server or P2P applications i.e. you send a message to an address and you receive messages on a specified port. The differences will come in at the protocol layer, but this has nothing to do with asio per se.
The following may or may not be of interest to you: there is no simple way IMO: users located behind firewalls and NAT means that you need to use techniques such as STUN, TURN and ICE to resolve addresses or in the worst case relay data. All these designs require a server.
Reading about WCP (woof, what a monster of a subject), and just into the earlier stages of what transports are available. I note that TCP is available, but not UDP. Is this because UDP is not always reliable...lossy with packets ?
Thanks,
Scott
No official reason for that. Who knows may be we will have netUDPBinding in coming releases.
But most probably they gave priority to TCP as it is reliable.
I would certainly think so. UDP is useful for streaming video or audio, not for reliable messaging.