Only one subflow over LTE and one subflow over WiFi, or a number of subflows over LTE and WiFi?
Thank you.
#Lena I'm afraid your answer is not %100 correct. MPTCP as well as TCP use "pairs" of IP's and ports. So, the limitation of subflows is mainly in the port quantity. Thus, it is possible to create more than one subflow between two IP.
And what for? It is mainly to give more robustness to the connection. You can transmit the same thing from two subflows, and then compare it in the destination.
But it can be used to obtain a higher throughput too. Where? Imagine you have a mobile phone with two IP addresses and a server with two network interfaces. You can create four independent subflows pairing IP1-IP3, IP1-IP4, IP2-IP3, IP2-IP4.
Mobile phone: IP1 (LTE) --- IP2 (WiFi)
Server: IP3 ---- IP4
In conclusion, you can use different configurations for different purpouses. But yes, it is possible to have more than 2 subflows with 2 network interfaces.
The subflow is still a TCP connection, so it needs an IP address. Usually, when the mobile is connected to WiFi, it has an IP. The same is for LTE. So the mobile device has two IP addresses available. That's why when MPTCP connection is established, it's one subflow over LTE and one over WiFi. If multiple IP addresses can be established over LTE or Wifi, then for sure multiple subflows can be created over one channel.
Related
I'm using the chrome://webrtc-internals/ URL to debug our WebRTC application behavior when the STUN/TURN servers are down. One interesting thing I'm noticing is that under "Stats Tables" there appear to be good, "peerreflexive" local ICE candidates being generated, for example:
Cand-2rjZ43jF (localcandidate)
Statistics Cand-2rjZ43jF
timestamp 10/24/2017, 9:19:39 AM
ipAddress 192.168.59.1
networkType unknown
portNumber 40555
priority 1845501695
transport udp
candidateType peerreflexive
The thing is this candidate never comes to me through the onicecandidate callback.
Is this just an internal quirk of Chrome or is there a way to get these perfectly good candidates?
I don't know exactly how this ICE candidate is generated. But as you can see, the candidate points to 192.168.59.1 which is your LAN IP address. So this candidate will only work for connecting to someone at the same LAN as you're computer.
My company is currently developping an embedded device running uClinux.
Those devices are supposed to be deployed in both un-managed and managed networks.
We are looking for the best strategy to assign static IP addresses (and subnet masks) to those devices (from a Windows computer on the network) when no DHCP (or BOOTP) server is available and save those values to a configuration file in the device.
This strategy shall avoid the usage of ssh, telnet or any similar interface.
The device would be set with a factory default IP address and netmask (i.e. something like 192.168.1.1). Ideally, the strategy woudl also enable us to activate or de-activate DHCP support in those devices. The MAC addresses of the devices would be known information available that could be used in any kind of tool running on a Windows computer.
Does anyone know if any standard way of doing such a thing does exists? Any recommendation ensuring possible future portability on other platform than uClinux is welcome. A combination of standard Busybox tools or uCLinux available tools would be ideal.
Thanks in advance,
Francois
I think the best strategy is to use Zeroconf, which in embedded linux can be achieved with Avahi. The idea is that the device automatically assigns an IPv4 or IPv6 address to itself and resolves conflicts of addresses if necessary.
Devices can be discovered on the network and you can access them even if you have services running on the board. The best strategy is to have an IP alias on the network card with the zeroconf address and on the main interface you put the address you prefer
[Warning: network programming newbie here]
We manufacture embedded devices that get connected to customers networks we know nothing about. They might or might not have DHCP enabled (but usually, they haven't).
What would be the easiest way to:
programmatically discover (I see several solutions for this) but also
CONFIGURE these devices (for example, CHANGING their IP address and netmask)
with a setup software we would ship with these devices? Would I be able to do the
"configuring" part with LLDP? Would I have to implement my own protocol on top of it?
Auto-configure is going to be as good as impossible if the network operator doesn't provide the facilities for it...
If you only need to communicate on the LAN then IPv6 link-local addresses are probably the easiest as they need no autoconf facilities.
LLDP is completely unrelated to what you need.
Is it possible ?
Peer-To-Peer connection via WiFi (same Access Point) , how would multiple devices talk on this layer.
Any API available or sources that can be looked into ?
Thanks
Yogurt
The Wi-Fi Alliance on Monday announced that its direct peer-to-peer networking version of WiFi, called WiFi Direct, is now available on several new WiFi devices. The Alliance is also announcing that it has begun the process of certifying devices for WiFi Direct compatibility.
Try researching the state of Bonjour / Avahi / Zeroconf on android. I'm seeing some pages that indicate people have made some progress for certain purposes but nothing like a generic howto or ready to use library.
Unless you know the IP address assigned to the other peer already, you'd have to somehow have devices inform other devices that they exist.
Are these devices definitely going to be on the same subnet? If so you can try messing around with having the devices send out 'broadcast' packets. I have no idea if the Android API lets actual applications receive these though.
The more reliable approach would probably be to run some centralised server somewhere that devices register with when they go online, and give their IP address when they register. Then they can query that server for which other devices are nearby and what their IP addresses are. If this is to be a central server out on the wider internet, then it means that unfortunately that the device discovery part isn't peer to peer - there is some privacy implication. Another thing if this is a central server is that you'll have to design the querying process to cope with NAT so that querying for other devices on your local network is restricted to the right network, but that you also get their IP address.
Is there any way to identify a users machine through a browser without previously putting cookies in? Probably no access to Mac Address through the web right? Just thought I'd ask...
There is no such identity element, and even if there were, the nature of the HTTP protocol would not prevent it from being spoofed.
In short: No.
This was partly why Intel tried to have unique processor IDs a few years back, but that didn't ever take off. (Which is good as now we have multi-core machines.)
Just install a cookie on the box. IP address is no good because of Natting. Someday we'll have IPv6 to do this correctly.
You could retrieve an IP address, but it frequently wouldn't mean much (if anything). If you retrieve the IP address the client is using, you'll get a whole lot of them that are 192.168.*. If you retrieve the address your server sees, it won't match that, and you might easily see several (possibly hundreds or even thousands) of machines with the 'same' IP address.
If you put those two together, you'll get something that's unique for the moment, but is subject to change at any time. The client's local IP address may change when their DHCP lease expires and their global IP address may change anytime they reboot their router (unless they have a static IP address, which you mostly don't have any way of knowing).