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
what would be the good starting point to learn TCP Socket programming using java.
I have reasonably good experience in java software programming but new to netwrk/socket programming.
I am working on to develop a proxy cache server. But not able to read post requests/302/405 requests.
I referred to this below code.
http://blog.edendekker.me/a-java-proxy-server-with-caching-and-validation/
But unable to modify the code to read urls like www.gmail.com that return 302 Moved Permanently Error OR 405 Method Not valid Error. And also not able to read POST requests.
What would be the starting point where I can read about handling errors and handling POST requests.
Any reference links, example codes would be helpful.
My prev question in similar topic:
Handle a POST request and write response to client socket
Thanks
It looks like your problems are more related to HTTP than to TCP as such. Do you want to implement a proxy server in order to learn the HTTP protocol? If not, there are several good proxies freely available, often including source code. If you just want to learn TCP socket programming, try something simpler such as e.g. POP3. Also, if you want to do TCP in Java, be aware that there are 2 major ways to implement them:
One thread per connection
One thread per application, shared between connections (Java NIO and NIO2)
Assuming you really want to tackle the HTTP proxy. HTTP is not trivial if you want to implement all of the functionality that e.g. browsers use, like caching, authentication, etc. plus the additional complexities that incurs when implementing a proxy.
If you really want to bite the bullet, here's a more lightweight version of the HTTP protocol, for all the details, refer to RFC 2616 . But be aware that RFC 2616, the HTTP 1.1 specification, refers to other RFCs that you might have to consult as well for specific areas such as authentication.
Update:
One other thing that might be easier in some cases is using an HTTP proxy to sniff the communication between say a browser and an off-the-shelf proxy to quickly see what others are doing.
Related
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 6 years ago.
Improve this question
In our company we use spring boot, microservices, spring cloud and so on... We are happy with this infrastructure, but I still have some concerns:
we use rest as comunication protocoll and even if a I find it great, I still think that we could find something better. With rest:
you need to use a client and a server (restcontroller)
you need to know the server URI, the http method (POST, GET, PUT,...)
you need know where params go (body, querystring)
....
Don't you think It would be much easier if we had something like RMI? I know it's a quite old technology(and it's not language independent), but it made life easier (you just need an interface and its implementation).
Searching around, I found some interesting projects like feign clients or spring cloud stream, but none of them seem to be the silver bullet.
What do you think about this topic? Is that a problem that you feel? If so, how do you approach it?
Thanks in advance.
In my company, we use JMS to add a "intern" communication stack to our microservice stack. It is reliable, simple to use, efficient and very performant.
We use Apache ActiveMQ as implementation, but RabbitMQ is also widely used.
Microservices are not meant to be tightly coupled , RMI requires your code on both end , which was fun when you didnt control the other side eg clients who do not want to upgrade and it was a B!#*! to get through firewalls.
Soap solved most of those things you mention unfortunately Java never had a good Soap stack. That said Rest has other advantages especially when accessing the service from a web page and javascript.
You can use Spring Cloud Netflix and Eureka as Service Discovery and Client-Side Load Balancing with Ribbon.
With the help of those you can communicate between microservice by 'service names' instead of service locations.
Check out this demo. It should be VERY USEFULL for undestanding microservices communications.
Here we have 2 simple microservices and Discovery Service for communications between them.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm working on a project that involves several applications on several computers. The main application is a C++ socket server running on a CentOS server, and the client application is a Java program running on client PCs.
These will communicate back and forth using sockets. I have defined a set of commands and arguments that they will need to implement in order to support everything.
I've thought of several options, but I can't seem to find the perfect one..
Should the C++ and Java program write their own classes/parsers for validate the messages?
Should I create an XML file (served over HTTP) that defines all of the communication messages? (That the server/client would parse and create actions for)
Or use some kind of third party library (Google Protocol Buffers?)
The point is that when the Socket server sends a message X, then the client must know what to do with it. Same applies the other direction.
What would be the best way to implement this? Having the XML file would be nice, as the client/server may parse it and create methods/actions based on the data. But a more clearer approach would be to create classes that would do the parsing.
I always do this the binary way. First you must decide what underlying transport protocol to use, it could be UDP, TCP, TCS, SSL. I would start with the TCP, since it's very stable and easy to use.
A simple way to handle packages is by in each package begin with a number that specifies which package this is. The based on this number you send the package to a corresponding class that handles the data. This can be done easily in both C++ and Java. I think it's easier in C++ since there you can base don't he first number read in a entire struct, but in Java you generally have to read it primitive by primitive.
Remember that the standard over the internet is to use big-endian values, but the normal on the most machines today (Intel, AMD, ARM...) uses little-endian values. So in C++ you will have to flip all primitives before sending them. And you have to flip the received values as well. I don't know if Java does this for you...
ICE by ZeroC is a cross platform and cross language library for TCP/IP communication between C++ and Java. I've used ICE to communicate between Linux/AIX/Solaris for C++/Java programs without problems. ICE uses a binary transfer protocol that does the big-endian/little-endian conversion for you. The downside of ICE is that you need to define the messages and calls using its custom language.
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'm currently writing a simple client/server in Java using sockets. I want the server to make decisions based on different "commands" and/or serialized objects that are received from the client via the socket, and vice-versa.
Something like:
[Receive Command 'DoSomething' From Client]
[Call Method 'DoSomething' on the Server]
[Send result/status to Client]
etc...
Is there a convention for flow control like this using ordinary socket communication, perhaps with serialization? Should I be using RMI in Java instead?
I would recommend KryoNet for doing any RMI-type stuff without the overhead of RMI and the inflexibility it brings.
http://code.google.com/p/kryonet/
KryoNet makes the assumptions that it
will only be used for client/server
architectures and that KryoNet will be
used on both sides of the network.
Because KryoNet solves a specific
problem, the KryoNet API can do so
very elegantly.
The Apache MINA project is similar to
KryoNet. MINA's API is lower level and
a great deal more complicated. Even
the simplest client/server will
require a lot more code to be written.
MINA also is not integrated with a
robust serialization framework and
doesn't intrinsically support RMI.
The Priobit project is a minimal layer
over NIO. It provides TCP networking
similar to KryoNet, but without the
higher level features. Priobit
requires all network communication to
occur on a single thread.
The Java Game Networking project is a
higher level library similar to
KryoNet. JGN does not have as simple
of an API.
There is not. If you create client/server communication with sockets, you'll have to define your own protocol and the rules that apply for that protocol.
RMI may ease this step by executing specific object methods. The trade of is, the initial setup for the rmi server etc. which I've heard in recent years is not that hard as it use to be.
Here's a RMI tutorial you may find helpful
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
We want to push data from a server to clients but can only use HTTP (port 80). What is the best solution for messaging? One idea is Comet. Are there other ideas or frameworks which offer lets say JMS over HTTP. (Yes, ActiveMQ supports it too, but waggly IMHO. And JXTA supports it too but the configuration is complicated. Something simple is preferred.)
The simplest solution for many, many reasons is to use a Comet based approach (like you mention). This means the clients (to whom you want to "push" messages) open long-lived HTTP connections. Those connections stay open until they time out or you send the client a message. As soon as either happens the client opens a new connection.
Directly connecting to clients could be problematic for many reasons: they could be behind firewalls that disallow that, they could be behind proxies and so on.
Unless your clients are real servers (in which case you're really the client), have them contact you and send a response to mimic push.
Atmosphere and DWR are both open source frameworks that can make Comet easy in Java.
We used COMET in conjunction with JMS using WAS Web 2.0 Feature Pack; in effect the server did the JMS subscribe and COMET-pushed the message to the browser. as a developer it "felt" like the browser was subscribing to JMS. This "just worked" so we didn't look further for alternatives.
I could imagine a pure JavaScript JMS implementation in the browser, using HTTP as a transport but my instict is that this would be very heavyweight. I know of no such implementations.
The alternative approach to those already discussed (i.e. Comet etc.) is to implement polling in the client. The downside of that approach is that you inevitably have a delay from the time of the message/event and until the client receives it. If your application is very sensitive to such delays, polling is out.
If a certain amount of delay (at minimum in the order of a few seconds) is acceptable, polling is less of an abuse of the HTTP protocol. It is also more robust against temporary network troubles as the server by default queues messages and wont get upset if the client isn't available on its schedule.
I created an example app using Comet, Raphael, Bayeux, Java and Maven running PaaS Cloudbees and wrote a blog post about it, hopefully it will be helpful to someone.
http://geeks.aretotally.in/thinking-in-reverse-not-taking-orders-from-yo
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 have not had much experience with Webservices or API's.
We have a website built on Oracle->Sun App Server->Java->Struts2 framework. We have a requirement to provide an API for our system. This API will be used by other systems outside of our system. API is just for a simple SP that we have on our database. The other system does not want to connect to our DB to gain access to the SP but instead and an API as a 'webservice'
Can the community please shed some light on how to go about this? Will the API be put on our webserver? is that how the other system will connect to it? And how to go about creating a public API?
Some things you'll need to think about are:
SOAP vs REST (Why would one use REST instead of SOAP based services?)
How will you handle authentication?
Does it need to scale?
You might want to take a look at https://jersey.dev.java.net/.
It would also be helpful to look at how another company does it, check http://www.flickr.com/services/api/ for some ideas.
If you are using the Sun App Server, it should be fairly trivial to make an EJB exposed as a web service with the #WebService tag, and then have that EJB call the Stored Proceedure and return the data. The app server gives you tools to publish a WSDL which is what they will use to know how to call you API.
That being said, what sounds easy at 50,000 feet is a real pain to deal with all the details. First, what about security? Second, are WebServices really required, or is there a better communication mechanism that is more obvious, such as (at a minimum) REST, if not some simple servlet communication. And the hardest part: In exactly what format will you return this result set?
Anyway, you could be dealing with a bit of a political football here ("what, you don't know how to do web services, everyone knows that, etc.") so it can be a bit hard to probe the requirements. The good news is that publishing a web service is pretty trivial in the latest Java EE (much easier than consuming one). The bad news is that the details will be a killer. I have seen experienced web service developers spend hours on namespace issues, for example.
Soap or Rest or .. is one side of the medal and depends on what the clients want.
The other (more) important thing is the api design itself. Shall it be stateless or stateful. Are clients co-located in the same VM (Appserver) or remote in the same LAN or even in a Wan.
As soon as the communication goes over the wire, it gets slow due to serialization. So you want API methods to obtain bigger (but not too big) chunks of data at a time.
Or in other words, your question can not really be answered without knowing a lot more about what you want and need to do.