The setup is Glassfish 2.1.1 and a Java standalone client. Connection is via IIOP.
Our client produces an enormous amount of traffic on the wire and I'm trying to
find out where this comes from.
From my understanding the protocol hierarchy should look like
Ethernet -> IP -> TCP -> GIOP -> CDR
Up to GIOP this is what I see in Wireshark, but the payload of the
GIOP messages is unclear.
Unfortunately Wireshark doesn't dissect the payload of the GIOP-Messages.
I thought the GIOP Messages should contain Java objects
serialized with CORBA CDR, because that is the CORBA serialization.
(After all for non Java clients, I'd had to generate IDL, so CDR should be
used anywhere).
What I see in Wireshark is lots and lots of
XRMI:java.util.Collections\U0024SynchronizedCollection:
followed by a Hex-String and a few bytes of binary data, then again XRMI:.....
From this I suppose it's RMI and I have RMI over IIOP,
giving me
Ethernet -> IP -> TCP -> GIOP -> RMI -> Java Serialization
But if the GIOP payload is RMI where does CDR fit in.
How can I interpret the payload of the GIOP messages and
where can I find a spec for RMI over IIOP?
RMI over IIOP is just CDR over GIOP as you have above. It's not a different protocol and it does not use Java Serialization. Its whole purpose is to be compatible with CORBA.
Related
We have an enterprise solution deployed on Wildfly 8.0.0 server, we intend to support CoAP and MQTT also as communication protocol. We explored extensively but we couldn't find even any oblique reference to our problem case. Is it possible to add CoAP and MQTT support without destabilizing Wildfly setup ??
I think theoretically it is possible to use a https://www.eclipse.org/californium/ within an EE server for CoAP.
The main issue here is that Californium listens to an UDP port (and sends datagrams too).
So if you want to stay within a EE specification, you'll have to implement a JCA adapter for that.
If you want things to just work, you can run/manage it from a JMX bean.
WildFly being a Web Server doesn't necessarily need to support CoAP or MQTT because those are not standard HTTP based Communication protocols but protocols designed to enable M2M (Machine to Machine) Communication.
As of WildFly 8.0.0.Final it only allows HTTP (Servlet, JAX-RS, JAX-WS), Web Sockets, HTTP Upgraded Remoting (EJB Invocation, Remote JNDI).
The UDP ASSOCIATE request is used to establish an association within
the UDP relay process to handle UDP datagrams. The DST.ADDR and
DST.PORT fields contain the address and port that the client expects
to use to send UDP datagrams on for the association. The server MAY
use this information to limit access to the association. If the
client is not in possesion of the information at the time of the UDP
ASSOCIATE, the client MUST use a port number and address of all
zeros.
From RFC 1928, I interpret the text as that the DST.ADDR and DST.PORT is only useful for limiting access to the association(I take limiting access as preventing sending UDP through the association)，this makes sense to me.
By following the RFC, I already implemented client -> proxy -> remote for UDP relay.
Now the confusion I am having is how to implement remote -> proxy -> client, WHAT port to listen for remote packets and WHAT port of the client to forward the packets to? The RFC does not states this clearly.
I'm developing a SIP parser in C (client only) and i have doubt about, do i need to bind a socket with a specific port (5060) on double nat?. What i'm sure about it's that is really important in the server side but i'm not really sure about the client side
You don't have to use port 5060 on the client side regardless of the NAT type. There is no any disadvantage if you just pickup a random port. The only recommendation is that once you pickup a port, keep that across sessions to help NAT bypassing a bit in some circumstances and to not overflow NAT's with various binding.
Even on the server side you can use any port, but there is a big disadvantage: users need to type also the port part as the server address (yourdomain:port) if you are not using the standard 5060 port.
Think about it like in case of http. On the web server the standard port is 80. However none of the clients (web browsers) are using port 80 on the client side.
I connect to a web server supported by an embedded system with Internet Explorer 9. Windows 7 is on the client side.
The web page have many tabs and I browse across until the problem occurs. It takes about one minute to happen.
The embedded system freezes so it not possible to browse and it does not respond to ping. After a moment the embedded system will recover because it is designed to reboot. I joined a Wireshark trace in which you can see 92 connections (use the filter "tcp.stream eq 0" with values [0,91]) and you will see. I have the source code so I know that the embedded system does not support more than 37 simultaneous connections. Is the cause an exhaustion of the resources?
But I have a more basic question and I really more appreciate an answer to it. The web server is at 172.21.1.12 port 80 and the client is at
172.21.9.70 and variable port numbers (see the trace). Because the IP and port on the server side do not change, how many sockets are in use on the server side? The question is important because the more sockets are opened, the more probably there is an exhaustion of the resources.
If the answer is only 1 socket then I must conclude there is no lack of resources because it can support 37.
I also suggest you use the filter ip.addr == 172.21.1.12 in Wireshark.
I thought I could upload the wireshark file. I dont know how to share it with you. Help please?
Dropbox?
Under the caveat that you haven't specified your embedded system, most TCP stacks will create a new socket for each new connection, and the mapping from socket to connection is 1-1.
When a packet arrives to the network stack, it has to associate that packet to the right socket. Usually, this is accomplished by employing a map from the TCP 4-tuple to the socket, where the 4-tuple consists of [local-ip, local-port, remote-ip, remote-port].
A server makes its service available by listening on a fixed local port that is known to clients wanting to use the service. As you understand, this is usually port 80 for a web server, and the software interface for most TCP implementations dedicate a socket for the purpose of allowing the API to perform operations on the network parameters for this service. However, the socket is not fully connected (the last two parts of the 4-tuple are set to a special "not specified" value, usually all bits 0). When a new connection is accepted, a new socket is created where the 4-tuple consists of the local information of the listening socket and the remote information taken from the source address and port of the SYN packet that initiated the TCP connection.
The limit on the number of connections a server can support is based on how the operating system is configured (you say yours limits it to 37). Using the 4-tuple, a single service (that is a fixed local-ip and local-port) will have an absolute limit of (2ADDR_BITS - RESERVED_ADDRS) × (216 - RESERVED_PORTS). For IPv4, the number of bits is 32, while for IPv6, the number of bits is 128.
When creating a connection, the client will specify the destination address and port (which fills out the remote information for the 4-tuple), but usually leave the source information unspecified. The TCP stack will choose an appropriate source address based on routing, and select an available source port (which will become the local information to complete the 4-tuple). In theory, any source port that is not being used by the selected local interface to communicate to the same remote service can be used as the local port. Most stacks will dedicate a set of the higher numbered ports for this purpose (referred to as the ephemeral port range).
I need to implement a TCP server with a web interface included for management.
Basically, the tcp server will be listening to new connections and keeping current ones active while the web interface allow me to see information regarding these connections and to interact with them (e.g. send messages and seeing received ones)...
My concerns resides in the "TCP Server" integration with the web application.
For received messages I could simple use a shared DB, but I need to send messages to the peers connected into the TCP server.
My best bet is currently on JCA. Some research pointed me to a nice sample: http://code.google.com/p/jca-sockets.
The sample uses an Message Driven Bean to deal with messages received over port 9000, acting as an echo server.
I am new in the Java EE 6 world. I trying to figure out why things were done in one way or another in the sample (e.g. why MDB?).
JCA has a fairly complicated spec. So I am trying at first to adapt the sample above to keep the connections active to exchange data. My next step will be adapt it to accept a string over a servlet to forward it to a given peer.
Can someone help me out on this?
Well, first of all, using Java EE with TCP is not the best approach you may use. If you just need a simple TCP service with Web UI you'd better consider using Java SE with some web container attached (undertow works well).
In other hand, if you need your application to integrate into existing Java EE infrastructure your company has, JCA would be the best approach. While it's not designed for such kind of things, JCA is the only EE subsystem liberal enough for that kind of thread management you would need for TCP networking to work.
JCA-Socket you're referring above is not the best example of a JCA app. It uses plain Java's blocking sockets by blocking WorkManager thread, this is not very effective. Things got much better now and we have Java NIO and Netty for highly effective raw networking to work upon. I have a JCA connector for TCP interactions which may provide you a skeleton to build your own. Feel free to extend and contribute.
P.S. About MDB: message-driven bean is the only "legal" JCA approach of asynchronous incoming messages handling. Since TCP is asynchronous, you'll definitely need one in your application for all the things to start working. Outcoming data transfers happen through various ConnectionFactory interfaces you'll inject into your bean. The link above will provide you with a reference ConnectionFactory implementation as well as a simple tester app utilizing both ConnectionFactory and MDB messaging approaches.