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
Related
I am not as familiar with web services and I'm having a hard time finding information about a question regarding the way clients interact with a RESTful web service.
I've implemented a REST web interface to interact with clients using Java and the Jersey JAX-RS library, however I need to limit the number of connected clients to 6. If I have 6 clients connected and a 7th tries to connect, I need to know if one of the other 6 has disconnected at some point so I can give the new client a connection. Is there a simple way to tell on the server side if a client is still connected? Do clients maintain connection in a REST web service after they complete a request to the server? Normally the clients I'm dealing with make HTTP POST and GET requests to the server at least one a second.
The only thing I can think of would be to ping each connected client and wait for a response in the event of another client trying to connect. If one ping times out then I could replace that client with the new one. But I'm not really sure how that would impact server performance. If anyone has any input on a way too accomplish this, I would greatly appreciate it. Thanks!
I have a problem where I have several servers sending HttpRequests (using round robin to decide which server to send to) to several servers that process the requests and return the response.
I would like to have a broker in the middle that examines the request and decides which server to forward it to but the responses can be very big so I would like the response to only be sent to the original requester and not be passed back through the broker. Kind of like a proxy but the way I understand a proxy is that all data is sent back through the proxy. Is this possible?
I'm working with legacy code and would rather not change the way the requests and responses are processed but only put something in the middle that can do some smarter routing of the requests.
All this is currently done using HttpServletRequest/Response and Servlets running on embedded Jetty web servers.
Thank you!
What you're after is that the broker component is using the client's IP address when connecting to the target server. That is called IP spoofing.
Are you sure that you want to implement this yourself? Intricacies of network implementation of such a solution are quite daunting. Consider using software that has this option builtin, such as HAProxy. See these blog posts.
So I have a server with a few clients.
When a client sends in a message I'd like the server to send it out to any one of the clients. However I don't really want the clients to be polling for messages, rather, I'd somehow like the server to check if they are online and then send them the message if they are.
I'm assuming the client will need a socket that's listening for incoming messages?
But what's a good method for the server to 'test' if the client is online? How the server know the address of the client?
I'm using Java with JAX-WS.
I'm sure there must be some method or design pattern for this that I'm not finding via google?
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.
I have a complete implementation of a protocol where four messages are exchanged between the client (a native Android application) and the server (a standalone Java server) in the following way using a persistent connection through Java sockets:
(client->server): message1
(server->client); message2
(client->server): message3
(server->client): message4
Between sending each message, both client and server have to do heavy mathematical (cryptographic) operations (pairing-based computations over elliptic curves).
This project works properly in my local development machine using sockets and mantaining opened this socket from message1 to the message4 between the Android app and the Java server. Now, I need to do the same with Google AppEngine, but since it does not allow opening sockets, I do not know how can I do it. I already checked the Channel and XMPP APIs, but I do not know whether my use-case applies to that APIs. Is it the right method using Channel and XMPP APIs from AppEngine? Is it possible to emulate the functionality implemented in my local machine through sockets on AppEngine?
Thank you for your response.
Google App Engine doesn't support persistent connections.
You will need to significantly re-design your protocol to run over HTTP.
As an example, message1 can be sent over an HTTP request, message2 can be returned with the matching HTTP response. At that point, your socket connection ends.
You'll have to issue a second HTTP request to open a new socket with message3, and you can return message4 with the second HTTP response.
You can "connect" the first and second HTTP request by using an HTTP session. A session is basically an id with extra data stored on the server side. You'd create the session in the first HTTP request, and pass it as a parameter to the second HTTP request. The server can look up the session id and the associated data when processing the second request.
You can find more info about sessions on SO: How to use session on Google app engine
The XMPP API will not help you, it's for communicating between the GAE server-side code and other XMPP clients that use HTTP as a communcation protocol.
The Channel API can be used to send data from the server->client, but it's actually implemented as an HTTP long poll. Multiple long HTTP requests are used, and you are not guaranteed to have a single socket that stays open; multiple sockets are opened and closed in the process. It will be more complicated that what I described above, and more expensive.