I have implemented a RMI solution, where my client program can get a datasource object from a DB pool in a Server program . Both run on local host (I am still a newbiew ;) )
But then I was looking at one of the posts in SO and it mentioned about wrapping a socket first and then use the RMI to access the remote access object.
Java RMI not closing socket after lease expiration
I also read that RMI also uses Sockets internally.
My question is if I have to create a wrapper on the Socket instance and then use RMI, should I create Sockets (server and client sockets) by myself and then use RMI....if yes...then how to do it? I have learnt to create sockets and RMI but not use them together.
Unless you plan to write and control the protocol for communication between client and server, stick to using an RMI client to interrogate a server and use the RMI server to respond.
Also, a DataSource instance is not something you should serialise and distribute to clients. Typically I would expect that when the client makes requests for data, that the server would use the data source to access data on behalf of the client, then marshall the results and send them back to the client.
Related
I'm going to create an authentication server which itself interacts with
a set of different Oauth2.0 servers.
Netty seems to be a good candidate to implement network part here.
But before start I need to clear some details about netty as I'm new to it.
The routine will be as follows:
The server accepts an HTTPS connection from a client.
Then, not closing this first connection, it makes another connection
via HTTPS to a remote Oauth2.0 server and gets data
After all, the server sends the result back to the client which is supposed to keep the connection alive.
How to implement this scenario with Netty?
Do I have to create a new netty client and/or reconnect it each time I need to connect to a remote Oauth2.0 server?
If so, I'll have to create a separate thread for every
outgoing connection which will drastically reduce performance.
Another scenario is to create a sufficient number of Netty clients
within a server at the beginning (when server starts)
and keep them constantly connected to the Oauth2.0 servers via HTTPS.
That's easily done with Netty. First you set up your Netty server using the ServerBootstrap and then in a ChannelHandler that handles your connection from the client you can use e.g. the client Bootstrap to connect to the OAuth server and fetch the data. You don't need to worry about creating threads or similar. You can do it all in a non-blocking fashion. Take a look at and try to understand how this example works:
https://github.com/netty/netty/blob/master/example/src/main/java/io/netty/example/proxy/HexDumpProxyFrontendHandler.java#L44.
Is it possible to fetch the IP addresses of connected clients to a server from the client side? I know it's possible server sided, but is it client sided?
Note: I'm talking about server-client connection using a basic Socket.
Only if the server purposely provides that list.
Otherwise, it is not possible to get any information of other clients connected to a server you are connected to (this, of course, applies to Java, but can also be understood as a general concept of networking -- in the context of peer to peer, client/server, sockets).
Not without a script or program on the client end of the socket having code to retrieve it (e.g. Javascript on a web page). You cannot tell this strictly from the server side.
You are talking with your server, and only server talks with other clients directly. So only server can send you clients ip addresses.
So, this is possible, but must be implemented on server.
I want to write a program in Netty4 that should act as a server to other clients and also it itself is a client to another server. How to do this in Netty4? So far all examples I have seen are either client or server. Thanks.
There are no special difficulties here. You need to create a part that will act as a server (using ServerBootstrap), and a part that will act as a client (using Bootstrap).
If you need to establish a connection to another server while handling incoming connection from a client, you can place that logic into a ChannelHandler of the server's pipeline.
Netty provides two examples of this approach:
Hex dumping proxy
SOCKS proxy
My service already uses Websockets to communicate with an HTML5 in-browser client. The client is served by the same server from a normal http request.
Now I would like to offer the same service/app but out of the browser, and I would like to offer it over TCP sockets.
The RPCs/action object I am using are going to be the same, the serialization is going to be the same, the logic is the same. I just want to use TCP socket instead of WebSocket.
I would like to keep the code together under the same "project folder", starting all at once when I deploy the playframework server (basically on start I want to start listening to WebSockets, TCP sockets and http requests), and have everything in the same package on deploy.
I know that:
It is not necessary, since WebSocket can be used in not-in-browser apps, but consider this an exercise or a curiosity question.
playframework is built on top of netty, and I used netty before to do some TCP services (nothing big and nothing prod ready though ... so not an expert). So they should work together right?
What I was thinking to do:
Have an akka actor listen for new socket connections.
Wrap the connections (WS or TCP sockets) into a ClientConnectionManager instance
Pass it to the actors that takes care of the connections/rpc logic.
Other leads I considered: Reimplementing the playframework Controller class.
Or is there an already implemented solution for this?
I have something like a proxy server (written in java) running between my clients and the actual video server (made in c++). Everything the clients send goes through this proxy and is then redirected to the server.
It is working fine, but I have some issues and think it would be better if I could make this proxy server only to listen to the clients requests and then somehow tell the server that a request has been made from the client side, and that it is supposed to create a connection with the client directly.
Basically in the TCP level what I want to happen is something like this:
1- whenever a client sends a SYN to my proxy, the proxy just sends a message to the real server telling the ip and port of the client.
2- The server would then send the corresponding SYN-ACK to the specified client creating a direct connection between client and server.
The proxy would then be just relaying the initial requests (but not the later data transfer) to the actual server. I just don't know if that is possible.
Thank you very much
Nelson R. Perez
That's very much the way some games (and Fog Creek CoPilot) do it, but it requires support on both the server and the client. Basically the proxy has to say to the client and server "try communicating with the directly on this ip and this port" and if they can't get through (because one or both is behind a NAT or firewall), they fall back to going through the proxy.
I found this good description of "peer to peer tcp hole punching" at http://www.brynosaurus.com/pub/net/p2pnat/
Does the proxy and server lives on the same machine? If so, you can pass the connection to the server using Socket Transfer or File Descriptor Passing. You can find examples in C here,
http://www.wsinnovations.com/softeng/articles/uds.html
If they are on the different machines, there is no way to pass connection to the server. However, it's possible to proxy the IP packets to server using VIP (Virtual IP). This is below socket so you have to use Link layer interface, like DLPI.
You don't have control of TCP handshake in userland like that. This is what firewalls/routers do but it all happens in the kernel. Take a look at the firewalling software for your platform - you might not even have to code anything.