Using sockets in java, is it possible to send information at the same time as connecting?
For example I want a remote device to control another device (such as a virtual appliance) using 'Client Server'. So the remote will switch the appliance on. When I connect to the Server I would like to allow the server to be able to determine what type of device it is, either a remote or appliance without sending a messages after connecting.
Is this possible? Or would there be a better way to implement this?
Thanks
You could set up different ports on the server, and have different kinds of devices connect to different ports. That way, the port number of the incoming connection would identify the device before the first byte of payload data has been transferred.
Related
I have implemented a simple P2P multicast network where each peer connected to the network sends data to every other peer. In order to make it possible, I made use of Java MulticastSocket Class, so every peer joins a multicast group defined by an available for multicast IP address, and a port number.
I got some issues while trying to run the program using EC2 services, where each generated instance represents a peer of the network, because the peers are not able to communicate in so far as exchanged messages do not reach the receivers.
Hence, basically my question is: is there a way to make EC2 instances communicate to each other using Java MulticastSocket? Can anyone help?
Natively, you can't.
Q. Does Amazon VPC support multicast or broadcast?
No.
https://aws.amazon.com/vpc/faqs/
Same thing for EC2 Classic (though there is hardly any reason you'd ever want to use that, if your account even allows it).
VPC looks like Ethernet, but it isn't. Put a packet sniffer on and try a ping. Watch the ARP traffic on both sides and you'll see something enlightening -- the source machine arps for the target and gets a response, but you'll see neither of these packets on the target machine. The ARP response comes from the network infrastructure itself.
There's a workhackaround, if you're feeling crafty: you can build an overlay mesh network that transports multicast over unicast.
See https://aws.amazon.com/articles/6234671078671125
I want to develop network application (servers-clients) with some process:
server creating instance on specific port and sending to other client in network information about existance (can be invitation message);
clients are checking about existing servers in LAN network on specific port. Choose which one to connect and do other actions.
I tried ServerSocket and Socket and I know how to connect one server to one client. But to do procedures described above I need to do something like broadcating. Which method should I use and try? Is MulticastServer good for that one?
Thanks for help.
We are working on a Android project with the below requirements.
The application should be able to send data to all the devices which are running our application which exists in the WiFi LAN.
Some payloads are expected to be of size >= 5MB.
The data shouldn't be lost and if lost the client should know the failure.
All the devices should be able to communicate with all other. There will be no message targeted to a specific device instead all the messages should be reached all the devices in the N/W.
No internet hence no remote server.
Study we have done:-
UDP Broadcasting - UDP doesn't guarantee the message delivery but this is a prime requirement in our case. Hence not an option.
TCP - TCP guarantees the message delivery but requires the receiver IP address to be known before hand and in our case we need to send the message to all the devices inside the LAN. Hence not a straight option.
Solutions we are looking into:-
A Hybrid approach - Name one of the devices in the N/W as Server. Post all the messages to a local Server. The Server keeps a open socket to all the devices(which have our application) & when there is a message from a device then it routes the message to all the devices. The disadvantages of this approach are,
Server having multiple sockets open each per device. But in our case we are expecting devices <=5 in LAN.
Server discovery using continuous UDP broadcast.
We want to have all the data in all the devices. So if we newly introduce any device into the LAN then that device needs to get all the data from the server.
So my question, have you any time worked on these kind of hybrid approaches? Or can you suggest any other approaches?
Your hybrid approach is the way to go.
Cleanly split your problem into parts and solve them independently:
Discovery: Devices need to be able to discover the server, if there is any.
Select server: Decide which of your devices assumes the server role.
Server implementation: The server distributes all data to all devices and sends notifications as necessary. Push or pull with notifications does not matter.
Client implementation: Clients only talk to the server. The device which contains the server should also contain a normal client, potentially passing data to the server directly, but using the same abstract protocol.
You could use mDNS (aka Bonjour or zeroconf) for the discovery, but I would not even recommend that. It often createsmore problems than it solves, and it does not solve your 'I need one server' problem. I would suggest you handcraft a simple UDP broadcast protocol for the discovery, which already tells you who the server is, if there is any.
Select server: One approach is to use network meta data which you have anyway, for example 'use the device with the highest IP address'. This often works better than fancy arbitration algorithms. Once you established a server new devices would use this, rather than switching the server role.
Use UDP broadcast for the discovery, with manual heuristic repeats. No fancy logic, just make your protocol resilient against repeated packets and repeat your packets. (Your WLAN router may repeat your packets without your knowledge anyway.)
You may want to use two TCP connections per client, potentially to two different server ports, but that does not matter much: One control connection (always very responsive, no big amounts of data, just a few hundred bytes per message) and one data connection (for the bulk of the data, your > 5 MB chunks). This is so that everything stays responsive.
I need to have a UDP server which allow me to receive/send informations from/to clients which dynamically will open a socket with a free port (so it will be differente from device and device). The client will send and receive in the same port, so the server must be able to communicate with it.
how could I set the server to stay open in every port? if I had 250 thousand users how could I handle them without tails problem and preventing the port to be occupied from another client?
I thought about open every port with different sockets in a different thread, but I don't know if this is a correct way.
A UDP Server can listen and be open on only one port. All clients can send data to that port. The server will have to handle each data and respond if needed to the peer who sent its data. This should happen even if more than one client wish to send data to server. In UDP context one client will not hog the server port.(Unless the application is badly written).
I'd like to know how a central server works in connecting two devices. I'm assuming that when the device application starts up, it should register its IP address and other pertinent information (username) with the server. When it wants to connect to another device, it should look to find the address of another device on the server, maybe with a get request. Then set up a to connect to a socket. If the device application closes, it should unregister from the server. Is this correct?
That's pretty much correct.
Because one or both devices are probably behind firewalls (including NAT), you have to assume they won't actually be able to connect directly to each other, so it won't be as simple as opening a socket to the other device once you find out its registered address. You will either have to try firewall-traversal techniques (which will usually be successful with UDP but not with TCP) or have a helper that isn't behind a firewall (which could be the same as the registration server or something else) carry all the data between the devices that wish to communicate.
Also, you will want to have the registration server time out registrations and the clients periodically refresh them, because clients won't always have a chance to deregister themselves on the server when they terminate or lose access to the network.