Our project involves streaming captured pointCloud images from Xtion Pro Live to be transmitted wirelessly from a raspberry pi to a laptop. We propose to use UDP over TCP since UDP is faster than TCP. However, we also wanted to let the raspberry pi detect if it has lost its connection to the laptop. But since UDP is connectionless, here are the solutions that I can think of:
1.) Use TCP for detecting connection and UDP for streaming pointCloud
2.) Use UDP for streaming PointCloud and in the raspberry pi, it has to receive a frame from the laptop within a time window which this should serve as the detection for connection.
3.) Use TCP.
What should I use?
TCP, would be the most pragmatic option. Look how many images we receive on a single web page - that's all sent using TCP. There would be a lot more work required than detecting dead peers if you were to use UDP - you would also have to deal with dropped and duplicate packets, congestion control...
Related
For a week I've played with cheap modbus RS485/Ethernet adapters like USR-TCP232-304. I was assuming they would "speak" modbus TCP on the ethernet side and modbus RTU over RS485. After countless experiments I've found what that these adapters are actually expecting is RTU over TCP on the ethernet side, so they're not repackaging the ADU/PDU but simply relay.
Is this a standardized way of doing modbus or do I simply misunderstand what's going on?
Looking at the datasheet for the USR-TCP232-304 I see no mention of Modbus support; it's a RS485 Serial to Ethernet Converter only. These units makes no attempt to understand the data flowing over the link (if they receive a byte via RS485 they send it via the TCP link and vice versa). They can be used to talk to pretty much any device that uses RS485 (there are a lot of other protocols that run over RS485).
Modbus RTU transmitted via this kind of unit is pretty common if not exactly standardised (it's not mentioned in the modbus spec to my knowledge). Often these devices include drivers that present themselves as a serial port so, from the applications perspective, there is no real difference between direct RS485 and going via one of these devices (other than timings).
It looks like the next model up includes a modbus gateway function that will act as a Modbus TCP server (and there are plenty of other options; they generally cost a bit more because of the additional processing required).
I developed a C++ app to stream video from a webcam on an Odroid device over UDP. The client is an iPhone app using simple UDP sockets and it works perfectly over Wi-fi, but not over LTE. The sendto() call works okay, but the recvfrom() blocks forever. First I thought it has to do with iPhone blocking UDP traffic, but I also tried a client on my laptop connected in the iPhone's hotspot and thus over LTE.
Do you think there is something with phone providers blocking UDP traffic?
I preferred UDP instead of TCP for faster streaming.
Any advice would be highly appreciated!
Thanks!
UPDATE: I found the cause of the problem after some further inspection. It turns out that UDP over LTE sets the IP_MTU_DISCOVER flag and if the user's packet is larger than the device's MTU, it does not perform IP fragmentation but simply drops the packet. My application is sending packets larger than MTU, but in the case of Wi-fi they are fragmented in the IP layer. If you disable the IP_MTU_DISCOVER flag, the large packet is fragmented and arrives successfully in the destination. The other alternative would be to send packets smaller than MTU from the application. Both approaches do not perform that well, but at least the mystery is solved.
I have installed Kamailio as sip server/registrar and using default config.
I have this situation:
mobile cleint using IMSdroid (extension 100)
windows client using Linphone (extension 300)
Register satus: both clients register successfuly
Both clients get connected to kamailio using my Wireless WIFI modem.
I dial (from IMSdroid) to linphone:
Both ring OK.
Audio heard in IMSdroid is OK.
Audio heard in windows linphone is just wind sound and jitter (or train sound, when I speak louder it gets louder)
Video is ok in both sides (both clients show video clearly)
Both clients get connected to kamailio (public internet IP)
What the problem is from?
You say both softphones and Kamailio are using public IP addresses, if you don't force RTP relaying with rtpproxy (or other similar application), then the RTP streams are sent directly between the softphones.
It might be a bug of the softphone, a problem with the network or audio card, a misconfigured local firewall or maybe the carrier is blocking VoIP.
Try to use other softphone, like Jitsi or X-Lite and see if you get same problems.
I am building an Arduino based servo driver that I want to control with OSC commands from my iPad over the Internet.
Is it possible to send OSC commands over 3G / UMTS with my iPad or iPhone to control a device? So I will not be limited by the router's range when I send OSC commands to the controller when both devices are part of the same Wi-Fi network.
It seems that the applications I downloaded (TouchOSC, iOSC) can only send OSC data over Wi-Fi, however I'd like to send the commands over the Internet (with port forwarding settings in my router).
I would get one of these. Look ma, no wi-fi :)
OSC typically uses UDP (User Datagram Protocol), even if some newer OSC implementations also allow TCP/IP messaging (also see Difference between TCP and UDP?).
Unfortunately (as far as I know), UDP does not work over 3G, which seems to be your problem. In other words: two mobile devices cannot talk to each other on a cellular network. So it has nothing to do with OSC apps not being able to do this, it's just not available from the cellular network.
However (I think, not tested), I see two workarounds here:
try to use TCP/IP instead of UDP to send your OSC packets
if you need UDP on the Arduino side, you could use a server in-between
Do port forwarding on your router to forward port x to the Arduino, and then use the IP address from whatsmyip.com and use that one in the touchOSC app when inputting the IP address. That may work.
I need to send and get packets via UDP and TCP in iPhones and the server. But, I figured that if I wanna send packets to a client (iPhone), he is... A kinda server.
So, let's say I'm sending and getting packets to iPhone via the port 2347. Do I need to open the port on the iPhone or something like that? Is there any Firewall built-in to the iPhone?
No firewall on the iPhone. However, 99% of the time, the phone will not have a publicly accessible IP. It may be on wifi behind a router, or it may be on the cellular network most probably behind a NAT pool. Either way, you don't have access to any of those pieces of equipment, nor do your users in the cellular context (and potentially some cases of wifi usage). Think about doing this another way.
There is no firewall on the iPhone by default. Provided you don't need the iPhone to act as a server, i.e., bind a port, you can have the server send packets back to the iPhone using the information in which they were received, i.e., IP and port, using the protocol of your choosing, e.g., TCP or UDP.