I'm new to Esper and am interested in using it to send event data via a network so consequently interested in the EsperIOSocketAdapter
It appears that SocketAdapter can only bind to a specific port which is fine if there is only one network adapter but is it possible to configure the SocketAdapter to bind to a specific network adapter too by specifying its IP address?
Please create a Esper JIRA if you need this feature.
You could also use the Esper API directly and use your own Java socket transport.
Related
I am using the Ryu Controller to send the packets from source to destination. I want to check the delay and bandwidth of the links created. How can I access these parameters?
You can:
Either configure this in the topology when you are setting it up
Use Ping/Iperf to figure out what the delay/bw is respectively
Check the configured interface's parameters using TC to get access to this.
I have a Linux server with multiple network interfaces. Each interface has its own IP address.
How to force HTTP requests to use a specific interface by specifying its IP address? Just like curl --interface command line option.
You'd need to build your own HttpConnector probably starting from the vanilla connector, perhaps using net2::TcpBuilder.
This is definitely something that seems like it should be easier, perhaps specified in the config. You might want to open an issue for hyper or submit a pull request if you implement it yourself.
Currently, I'm writing an application on top of Ryu, the Open-source OpenFlow Controller.
To create an OF-Config connection (or OVSDB connection), I think I have to get the IP address of each switch connected to the Ryu controller. However, I cannot find the API that converts the Datapath object or datapath id to the IP address of the switch.
So, if there is such an API, I want to know about it. If not, I'm looking forward to receiving some comments about the way to make the connections without the IP addresses.
#set_ev_cls(event.EventSwitchEnter)
def switch_features_handler(self, ev):
address = ev.switch.dp.address
dpid = ev.switch.dp.id
"address" is a tuple of (ip_address, port) and "dpid" is the datapath id.
Byungjoon are you using mininet?
If you are, all the switches are instantiated with the localhost ip address (This is mininet's default behavior). The controller distinguishes between switches using the tcp port.
As far as I know, you only need to know the dpid of the switch in order to send OF messages. This is what the sample l2-learning switch is doing: https://github.com/osrg/ryu/blob/master/ryu/app/simple_switch_13.py
I am also try to communicate with the switches using Ryu controller. I am using the above sample as my basic code and adding on top of it. It is not done yet (so you might see some bugs) but it's good starting point. Here is the link: https://github.com/Ehsan70/RyuApps/blob/master/l2.py
for latest version of ryu, you should use following code.
#set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
def _switch_features_handler(self, ev):
print(ev.msg.datapath.address)
When programming in linux sockets, we are invoking the standard libraries socket(), connect(), send() and so on, but if we have two network adapters connected to the same LAN, can we choose one manually or it depends on the route table configured by the administrator that we can't change or something else?
Well, you can specify interface with bind(), since every interface has its unique IP address.
I'm going through the Whitepaper by RADVISION on NAT/Firewall traversal for H.323 endpoints.
It is suggested there to use ITU-T H.460.18,17 and 19.
460.17 is very clear way for NAT traversal, but I'm not so clear about the 460.18.
Both present a clear solution for Firewall, but how is 460.18 a solution for NAT traversal?
Regards,
H.460.18 works by opening pinholes when moving from one protocol/network connection to the next.
H.323 works in the following classic way to connect a call:
RAS is used over UDP to register to the gatekeeper
Q.931 is used over TCP (usually) to initiate a call
H.245 is used to negotiate media capabilities and open media channels
RTP/RTCP is used to send actual media
Now, to be able to open up Q.931 and H.245, you need the endpoint to be listening on a TCP address for incoming connections. If the endpoint is behind a NAT - that will be impossible to achieve.
So H.460.18 adds special messages to get these TCP connections from the inside out (=reverse).
On RAS, when a new TCP connection needs to be opened for Q.931, a RAS SCI (ServiceControlIndication) message will be sent to the endpoint so that the endpoint will open up the TCP connection for Q.931 instead of just waiting to get an incoming connection.
On Q.931, when a new H.245 connection needs to be opened, it is initiated today already on Q.931; but now it will always be done from the endpoint behind the NAT to a public address.
To sum it up:
H.460.17 uses a single connection outbound from the endpoint to the gatekeeper and then just tunnels everything on top of it.
H.460.18 just opens up a new pinhole from one protocol to the next by having the endpoint behind a NAT do the connecting instead of doing the listening.
The problem with H.460.17 is that virtually no H.323 equipment supports it.
H.460.18 works nicely, even across vendors. It lets the endpoint behind the firewall poke a whole and then uses that whole for both ways of communication. Its rather simple when you read though the standards document. But beware that it is patented by Tandberg, so you have to get a (free) license before you can implement it.
You can look at the GNU Gatekeeper to see the details how H.460.18 gets through the firewall.