I am using RMI Replication in ehcache for my clustering needs.
There is a doubt here,
To replicate the cache updates(puts/updates/removes), does RMI use UDP multicast or TCP multicast?
RMI uses TCP multicast to replicate the cache updates
Actually, it uses UDP, despite the docs claiming it's TCP.
First, TCP multicast is not possible.
Second, if you look at the code of MulticastRMICacheManagerPeerProvider, it uses MulticastKeepaliveHeartbeatReceiver and MulticastKeepaliveHeartbeatSender which both in turn use java.net.MulticastSocket. Here is some javadoc from that class:
The multicast datagram socket class is useful for sending and receiving IP multicast packets. A MulticastSocket is a (UDP) DatagramSocket, with additional capabilities for joining "groups" of other multicast hosts on the internet.
Related
I see this sort of address used in a bunch of examples. What does it mean exactly? Does it mean it will connect to any/all machines on the subnet that have something listening to that port? Or something else entirely? I see such usage in the docs and in books without explanation. Sort of annoying.
It is explained in the manual.
ZeroMQ supports multiple transports. tcp means you are using the TCP transport.
The address (or endpoint) for the TCP transport has the following format:
tcp://interface:port
When you bind to a local address, interface is either the IP address of a specific interface (network) or *, which means to listen on all interfaces (networks). port is the TCP port or * for a random port.
When you connect to a remote endpoint, interface is the hostname or IP address of the remote machine. port is the TCP port of the remote endpoint.
To add to rveerd's answer, what's often missed is that you can multiply bind a socket. So, tcp://*:5555 specifies port 5555 on any interface and you can bind the socket accordindly. But by calling zmq_bind() again you can bind the same socket to, say, ipc:///tmp/feeds/0, which means it will also accept connections on the /tmp/feeds/0 IPC pipe.
This is a pretty spectacularly useful feature in my view, because you can trvially have other actors local and remote to the machine though a single zmq socket.
I can't connect to my queue on azure account using java code. It seems that the problem is the network. I can to connect with my private network but not with the company network.
I have this message error:
Exception in thread "main" http://com.microsoft.azure .servicebus.primitives.ServiceBusException: Error{condition=amqp:connection:framing-error, description='connection aborted', info=null}.
Any hints?
It seems that the problem is the network. I can to connect with my private network but not with the company network.
Yes, you are right. I also find the simlar issue on the github. It seems that your company firewall restriction which blocks all traffic on ports 5671 and 5672. We could get more information from AMQP 1.0 in Azure Service Bus and Event Hubs protocol guide.
Azure Service Bus requires the use of TLS at all times. It supports connections over TCP port 5671, whereby the TCP connection is first overlaid with TLS before entering the AMQP protocol handshake, and also supports connections over TCP port 5672 whereby the server immediately offers a mandatory upgrade of connection to TLS using the AMQP-prescribed model. The AMQP WebSockets binding creates a tunnel over TCP port 443 that is then equivalent to AMQP 5671 connections.
If possible, you could ask permission to open 2 ports in your company firewall.
Say for example, my machine is multi-homed and has two network interfaces:
Wireless LAN adapter WiFi : Ip: 10.20.19.140
Ethernet adapter Ethernet: Ip: 10.20.19.154
I create two UDP sockets one listening on (1) and other on (2). The i am assuming the interface is already assigned, then why do i need IP_MULTICAST_IF and IPV6_MULTICAST_IF?
The IP_MULTICAST_IF or IPV6_MULTICAST_IF settings tell your socket which interface to send its multicast packets on. It's a separate, independent setting from the interface that you bound your socket to with bind(), since bind() controls which interface(s) the socket receives multicast packets from.
(Granted, the BSD sockets API implementers could have made the assumption that a socket would always want to send packets out over the same interface it receives packets on, but that would make a number of use cases more difficult; for example, if you are using a single socket to receive multicast packets from all interfaces (via INADDR_ANY), then when sending a packet using that socket you'd still need a way to specify which multicast interface you want that packet to be sent over)
I have got some wireshark captures, and it shows that it is UDP. But in theory it says that it uses both TCP and UDP. So I m confused. And what is the difference b/w LDAP and CLDAP? Are they both UDP protocols?
Normally LDAP is a TCP protocol. But Microsoft uses LDAP also over UDP. See here:
http://msdn.microsoft.com/en-us/library/cc717362(v=prot.10).aspx
So it is both.
Lightweight Directory Access Protocol (LDAP)
The Lightweight Directory Access Protocol: The protocol accessing data from directory services like OpenLDAP, Microsoft Active Directory, Netscape Directory Server or Novell eDirectory.
Protocol dependencies
TCP/UDP: Typically, LDAP uses TCP or UDP (aka CLDAP) as its transport protocol. The well known TCP and UDP port for LDAP traffic is 389.
SSL/TLS: LDAP can also be tunneled through SSL/TLS encrypted connections. The well known TCP port for SSL is 636 while TLS is negotiated within a plain TCP connection on port 389.
https://wiki.wireshark.org/LDAP
I recently turned on Windows Firewall logging on my computer and started tracking incoming and outgoing connections. Something curious about the logfiles is that I have noticed numerous UDP packets (in fact, it constitutes basically all of my incoming traffic) that don't have my host as destination or source showing up in the logs.
I thought this might be a implementation detail for UDP (the packets are hopping over my computer in the subnet) but Wikipedia'ing UDP didn't enlighten me any more, and I don't see why my computer should be forwarding these packets in the first place.
Any ideas?
Edit 1: Here is what a log file line with the mysterious UDP packet looks like:
2008-10-11 16:04:31 ALLOW UDP 18.243.7.218 239.255.255.250 49152 3702 0 - - - - - - - RECEIVE
Is 239.255.255.250 a broadcast address? Now that you mention it, the UDP packets I'm seeing have very specific destinations, basically 224.0.0.252, 239.255.255.250, 18.243.255.255. I also get phantom ICMP pings addressed to 224.0.0.1.
The packets addressed to IPs starting with 239 and 224 are multicast packets. This is a way to address traffic to a group of computers without broadcasting it to an entire network. It is used by various legitimate protocols.
224.0.0.252 is the address used by the Link Local Name Resolution protocol.
239.255.255.250 is the address used by the Simple Service Discovery Protocol.
224.0.0.1 is the all hosts address, used by your router to see who on your network is willing to participate in multicast conversations.
The ones addressed to 18.243.255.255 look like broadcasts, again this is used by many legitimate protocols such as Bonjour.
As recommended by Luka, a good protocol analyzer like Wireshark will tell you precisely what each of these packets are and what they contain.
It depends on the type of connection you are on.
On most cable modem ISP's you are basicly on the same LAN as your neigburs, and can usualy see some of their traffic (like brodcast).
Id recomend you install packet sniffer and see what is realy going on.
Good multiplatform packet sniffer is Wireshark
Hard to say without analyzing the log data, but they could be broadcast packets on the segment, in which case you're system would listen to them. This is possible in IPv4 and IPv6.
Your system should not be forwarding them unless it's set up to route, but it can certainly be listening to packets all the time (various network protocols use UDP).