I wonder if there exist any other technologies used to establish internet connection between applications. Are there any other? I am searching and so far I haven't found anything else described.
There are many abstractions on top of sockets, if you don't want to deal directly with a socket API. UDP, TCP/IP, various RPC protocols, HTTP (which is on top of TCP/IP), etc. Many programming languages have easy methods of doing, say, an HTTP request and getting the resulting document. You can use that to allow applications to talk to each other over the internet without using a socket API.
What are you trying to accomplish?
If you want to skip sockets you basically have to implement your own means of talking to the network card hardware and telling it to communicate with other devices. A socket is just the abstraction chosen for *nix and Windows machines.
Related
I'm working on application running on JBossEAP 6.4 in domain mode. I need to handle multiple (up to 1000) parallel TCP connections from server to different hardware devices.
Connections have to be opened at server side and will be keept up to 90 seconds. All connections uses the same port and protocol, but destination IP adresses are different..
I wonder if JCA adapter is suitable for this use case. Should I create special Activation specification for every single device or use something else than JCA resource adapter?
The question is a bit old, but JCA is a not-that-popular technology so some knowledge about it would be useful despite of the fact you might have been implemented all the things already.
Firstly, JCA is a spec for writing your connector, it's not a connector implementation itself. If you need your application to work with external TCP it's up to you to implement a connector.
Whether JCA is suitable for your particular needs depends solely on the nature of your "different hardware devices". Resource adapters has been designed to be used on per-service basis with possible connections pooling. I.e. all the connections this particular adapter would fire should have quite similar nature and be interchangeable. However, JCA adapters also have sensible advantages outside of this scope, especially in EJB environment. EJB imposes quite harsh restrictions upon your code: no locking, threads spawning, etc. It might be quite difficult to implement TCP I/O without all those things. Here comes JCA and it's threading freedom (MDBs are capable of providing EJB-friendly scope on their activation despite of an underlying thread source).
In conclusion: you should consider using JCA for TCP networking if you're working in EJB environment (or if you're going to do so in observable future). If you're using Spring-powered environment upon Java EE stack it may worth to omit such a complicated technology and stick to some pure Netty networking.
If you choose to proceed with JCA, consider inspecting the JCA SocketConnector I am currently maintaining. It's build upon Netty stack and it could be a good start for you. You can also use it as a source of ideas how to build your own implementation instead.
I try to make a P2P Program and need help with getting through the NAT of the clients.
I have read many questions here on stackoverflow, but i never got what the drawbacks and benefits of all the Methods to get through a NAT are.
How many routers support which methods?
Which methods are commonly used by the big companies? (BitTorrent, TeamViewer,...)
What are the drawbacks/benefits of the three methods i listed and which else exists?
UPnP requires software support in your router. Even when routers have it, it's sometimes turned off due to security concerns.
STUN uses a simple public server to detect the presence of NAT and the real IP addresses. This is useful for other, higher-level protocols that do the useful work.
Hole punching is a simple technique to connect two computers. It requires a 3rd public computer to communicate between the 2 computers behind NAT. You could run your own server with a custom protocol, our you could use STUN and existing STUN servers. (Only a few packets are needed for setup, the rest are peer-to-peer).
Of course, some NAT firewalls are incompatible with the above, so you may need a custom protocol. Bittorrent does this: they use different techniques depending on which clients are behind firewalls and whatnot.
Quick question: do most chat applications (ie. AIM, Skype, Oovoo) use peer to peer UDP exchange for talking to other users or an echoing TCP connection with a server? Or some combination in-between?
Traditionally, most applications used a TURN-like solution (i.e., communication via a server) to overcome NAT traversal issues. Since chat does not consume much bandwidth, servers could support thousands of communications.
But now that P2P has evolved and the NAT traversal issues are now well understood, some use direct UDP communication provided that the users' NAT allows this (i.e., STUN-like communication). They still need a central server to punch the hole though. Direct communication is also helpful when lots of data needs to be transmitted.
I believe it is fair to say that most modern frameworks use a combination of both.
when you need small fragments of data, such as text messaging, there's no need of using P2P. data can be transmitted from client1 to server, and from server back to the client2.
When you need to transfer data quickly between clients, in cases such as VoIP (voice over IP), or file transfer, you will use P2P.
A pretty standard IM protocol is XMPP. I know it's used by Google Talk, as well as a few other big names in chat.
I usually pass data between my web servers (in different locations) using HTTP requests (sometimes using SSL if it's sensitive). I was wondering if there were any lighter protocols that I might be able to swap HTTP(S) for that would also support public/private keys like SSH or something.
I used PHP sockets to build a SMTP client before so I wouldn't mind doing that if required.
There are lots and lots and lots of protocols. Lots. Start here for a list.
http://en.wikipedia.org/wiki/Internet_Protocol_Suite
SFTP is fun for passing data around. It works well. You'll find that it's not much better than HTTP, however, because HTTP is pretty simple.
http://en.wikipedia.org/wiki/SSH_file_transfer_protocol
SMTP would work. http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
SNMP can be made to work. http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol You have to really push the envelope.
All of these, however, involve TCP/IP sockets, which involve a fair amount of overhead because of the negotiation for a connection and the acknowledgement of packets.
If you want real fun with very low overhead, use UDP.
http://en.wikipedia.org/wiki/User_Datagram_Protocol
You might want to use Reliable UDP if you're worried about messages getting dropped.
http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol
I'd like to mention XMPP in addition to protocols already listed in other answers.
It's lightweight, and it is used in some "realtime" communication systems (for example, in GTalk).
WebSocket is a good option if you are interested in keeping a connection open to pass multiple messages back and forth. It's useful for issuing updates from the server to clients in real time, for example.
Why don't you simply use FTPS:
http://en.wikipedia.org/wiki/FTPS
or SFTP
http://en.wikipedia.org/wiki/SSH_file_transfer_protocol
I'm developing a multi-player game and I know nothing about how to connect from one client to another via a server. Where do I start? Are there any whizzy open source projects which provide the communication framework into which I can drop my message data or do I have to write a load of complicated multi-threaded sockety code? Does the picture change at all if teh clients are running on phones?
I am language agnostic, although ideally I would have a Flash or Qt front end and a Java server, but that may be being a bit greedy.
I have spent a few hours googling, but the whole topic is new to me and I'm a bit lost. I'd appreciate help of any kind - including how to tag this question.
If latency isn't a huge issue, you could just implement a few web services to do message passing. This would not be a slow as you might think, and is easy to implement across languages. The downside is the client has to poll the server to get updates. so you could be looking at a few hundred ms to get from one client to another.
You can also use the built in flex messaging interface. There are provisions there to allow client to client interactions.
Typically game engines send UDP packets because of latency. The fact is that TCP is just not fast enough and reliability is less of a concern than speed is.
Web services would compound the latency issues inherent in TCP due to additional overhead. Further, they would eat up memory depending on number of expected players. Finally, they have a large amount of payload overhead that you just don't need (xml anyone?).
There are several ways to go about this. One way is centralized messaging (client/server). This means that you would have a java server listening for udp packets from the clients. It would then rebroadcast them to any of the relevant users.
A second way is decentralized (peer to peer). A client registers with the server to state what game / world it's in. From that it gets a list of other clients in that world. The server maintains that list and notifies the other clients of people who join / drop out.
From that point forward clients broadcast udp packets directly to the other users.
If you look for communication framework with high performance try look at ACE C++ framework (it has Java bindings).
Official web-site is: http://www.cs.wustl.edu/~schmidt/ACE-overview.html
You could also look into Flash Media Interactive Server, or if you want a Java implementation, Wowsa or Red5. Those use AMF and provide native functionality for ShareObjects including synching of the ShareObjects among connected clients.
Those aren't peer to peer though (yet, it's coming soon I hear). They use centralized messaging managed by the server.
Good luck