Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I need to implement a HTTP proxy server application which will proxy requests from multiple clients to a remote server.
Here are the steps:
Client forward request to proxy
Proxy forward request to server
Server returns request to Proxy
Proxy returns request to Client.
I'm just not sure how I should implement this proxy. My first thought was to implement a tomcat application which uses jersey / apache httpclient to forward the request to the remote server and return the response back to the client ?
Is there a better way to implement such a proxy server ?
The proxy would need to handle multiple threads.
You can't implement it as a servlet, and there is no reason to use any form of HTTP client.
A featureless proxy server is a really simple thing:
Accept a connection and start a thread for it.
Read the request from the client up to the blank line.
Extract the GET or CONNECT command or whatever it is and connect to the named host.
If that fails, send back an appropriate HTTP error response, close the socket, and forget about it.
Otherwise start two threads to copy bytes, one in each direction. Nothing fancy, just
while ((count = in.read(buffer)) > 0)
{
out.write(buffer, 0, count);
}
When one of those sockets reads an EOS, shutdown the other socket for output and exit the thread that got the EOS.
If the socket that was the source of the EOS is already shutdown for output, close them both.
Or use Apache SQUID.
Check out LittleProxy -- it has built-in classes for incoming and outgoing requests; you can just write your code similarly to how you would handle a HTTP request in a servlet.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I have ReST service, which calls a method to send the generated information to another endpoint using TCP, is there any way that with Jmeter that when I send a ReST request and should be able to host TCP server in my JMeter to receive the response sent when service called?
If you need to have a TCP server in JMeter you can get one using JSR223 Sampler and the following minimal code snippet:
def socketServer = new ServerSocket(1234)
while (true) {
socketServer.accept { socket ->
socket.withStreams { input, output ->
log.info("Received message: ${input.newReader().readLine()}")
}
}
}
it will start the TCP server on the port 1234, listen to incoming connections and printing the received data to jmeter.log file
More information on Groovy scripting in JMeter: Apache Groovy - Why and How You Should Use It
If you're receiving HTTP, not TCP you might rather want to go for HTTP Mirror Server which is listening to incoming HTTP connections and returns the received data
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I need to design the similar stuff like whats app or any messenger like module.
High level flow
Client > Load Balancer > Web servers(assume 10 clustered server for now) > Rest based controller > Service > DAO > DB
Challenge :-
say Friend 1 and Friend 2 are online . Friend 1 has established HTTP web connection to web server 1 and Friend 2 has established HTTP web connection to web server 2.
Friend 1 send the message to Friend 2.
Now as soon as message comes to web server 1, i need to convey the message to web server 2 so that message can be pushed back to friend 2 through already established web connection
I have couple of related questions here :-
I can use distributed queues to propagate the message from one server to another. As soon as message comes to one server , it will push it to distributed queue(distribute
queue because of load balancing and high availability) with message content, fromUserId, toUserId. My question how the right server (in this case web server 2) will be notified ?
because if i use JMS queue , only one server will be notified through listener. If i use topic all servers will be notified . In this case all servers can reject the message except the one server where fromUserId resides. Is there a better way where queue just notifies the right server based on some meta data ?
Also if destinationUserId is offline, i need to put back the message on queue. Not sure how it can be achieved ? I believe we need to use some other queue implementation(probably java based in-memory queue)
instead of JMS queue/topic ? Server code will only remove the message from custom queue once it gets acknowledgement from client.
If any client is offline at the time message is sent, in that case whe he coming online,he will send the pull request . Server will make the request to distributed queue
, distributed queue will pull the message from right physical queue. My question ia should distributed queue will keep the destinationUserId and message as value in metadata ?
DB vs Queue :- With this approach i believe there is no need to store the message in DB which can be costly(time complexity) than queue(in-memory queue) in highly real time application like messenger. We just need to store user/group details in db.
Update :- I found related link at quora where last point i.e. What protocol is used in Whatsapp app ?... by Kah Seng Tay also confirms the simialr approach using queue , but still my above questions on queue are yet to be answered.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
So I previously asked a question if you can send a client that's on a ServerSocket to a different Server. But now, I'm asking how are the players for minecraft sent from server to server using Bungeecord and/or Lilypad. I know that LilyPad uses proxies and that stuff, but how are the players, when connected to the Bungeecord/Lilypad server, sent to a hub/spawn and/or to other servers, for example a survival server and a creative server. You can find servers like this on servers that have networks. I know that Treasure wars uses lilypad, if that helps.
You answered your own question. Both Bungeecord and LilyPad are proxy server networks.
Though a server cannot redirect the client to another server without permission, the server can connect to another server (meaning the first server is a proxy) and send back that server's messages to the client. As the first server is, in essence, also a client to the second server, the first server can switch connections at any desired point.
In other words, the Minecraft client does not switch connections at any point. The IP of the server to which the Minecraft client is connected never changes, and it is that of the proxy. However, what does change is the server to which the proxy is connected. If the client sends some message to the proxy stating that it wishes to go to the hub, the proxy then disconnects from whatever server it is currently connected to, connects to the hub, and sends back to the Minecraft client whatever messages the hub responds with.
This is my understanding based on a quick search.
However, if the Minecraft client was modded as well, it would be possible to have a similar network without the need for a proxy like so:
Client interacts with the server in such a way (maybe the player walks into a portal) as to trigger some server-switching action.
The server recognizes this interaction and, as both it and the client are modded, knows how to respond. The response is simply the sending of a message to the client, saying, "Switch to a different server. Here is the IP: (Insert IP here)"
The client receives the message from the server and, by its own will, disconnects from the current server and reconnects to the new one.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I was planning to create a chat messaging application wherein two or more clients can communicate but I am a little confused.
Does java can have a client to client communication using sockets?
Does the socket communication always needs a server?
Is it possible that one client will stand a server of the communication?
Do you have any tutorials for a client to client communication?
If the communication needs a server, how a can a client A see Client B's messages?
Client to client communication does not makes any sense because once a system start receiving message it is termed as server, so in communication there should be a server and client to communicate else the situation will be like two people talking and none of them listening.
Client A can act as a server and client both and so the client B,
in doing so both can communicate in two way ie send and receive information.
Yes, java can work with sockets.
For example, an "official" tutorial from Oracle: http://docs.oracle.com/javase/tutorial/networking/sockets/
But working with sockets directly requires a lot of code for encoding/decoding message from/to a binary form, separating data stream to logical "packets", handling threads and message queues, etc. Fortunately, there are network libraries which make this process much more easier. I would recommend Netty: http://netty.io/
About client/server relationships. If we are talking about TCP/IP, then yes. One side (server) always listens for connection, and the other side (client) opens a connection to the server.
If you are using UDP, however, from network point of view, all participants are equal. They just send and receive UDP packets.
Back to your chat application: the most simple solution - all clients connect to the dedicated server. Every chat message contains client id. When the server receives the message, it sends it to the client with the specified id. Thus, every client can transfer message to every other client. The server works as a "dispatcher".
If you need simple approach you can try https://httprelay.io service. What you need is just http client and no external libraries.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I have two clients (A and B) and Servlet. I want, when A client send a request to the SERVLET, SERVLET redirected the request to the client B and client B send response back to the client A. CLIENT ARE NOT SERVLETS!!! They are ordinary socket clients, consequently IS NOT possible classic servlet redirect!!
Do you have any suggestions for troubleshooting???
Thanks a lot!!!!
Firstly, you can't serialize a HttpServletRequest or HttpServletResponse using Java serialization. Objects that conform to these APIs typically include references to "stuff" in the servlet implementation stack that is inherently non-serializable.
Second, you can't "redirect" a request to another client. It doesn't make sense from the perspective of the HTTP protocol.
A redirect happens when a client sends a request to a server and the server response has a 3xx status code that says "try that request somewhere else". It is a redirection to a different server, not a different client.
Even ignoring the details of what redirection means. You can't send an HTTP request to something that is in the HTTP client role. It won't be expecting it (listening for it), and wouldn't know what to do with it. (And indeed it would be a violation of the HTTP protocol.)
Thirdly, an "ordinary socket client" can't talk to an HTTP service (implemented using Servlets, or anything else). The client has to implement at least a subset of HTTP protocol in order to make itself understood by the HTTP service. It is possible to implement that "by hand", but IMO that's a bad idea ... when there are high quality implementations you can use for free.
In short, what you seem to be trying to do is impossible / nonsensical. (If I understand your Question correctly ... which is debatable.)
If you explained what you were actually trying to do here, we might be able to suggest sensible alternative approaches.
I'm trying to connect two java client applications across server. The client will be able to communicate directly with other client.
Literally you can't do that using HTTP. But you could build an HTTP server/servlet that transfers messages from one client to another; e.g.
Client A sends a PUT request containing a message for A to server.
Server stores message and replies to client A.
Client B sends a GET request asking "any messages?" to server.
Server looks up messages and responds with the message from A.
But note that you can't do that with plain socket clients. The clients have to be HTTP clients.
If you were prepared to ditch the requirement that the server was an HTTP server / servlet, you could have "simple socket" clients open duplex connections to the server, and have the server pass "messages" between the clients. This entails implementing a custom "protocol" for messaging.
A third alternative is to use an existing RPC or object broker technology; e.g. RMI, CORBA, ICE, etcetera