I am programming a bot that would emulate different users on one site. If all on the same port I wouldn't know a way to identify which virtual user should receive a data packet. I thought about opening multiple ports on one program, googled it, but I couldn't find information. Is it possible?
Yes, you can open multiple sockets, each listening on a different port.
The question is, do you need it?
If all on the same port I wouldn't know a way to identify which virtual user should receive a data packet.
You can build this into the protocol, for example a message consist of first the identifier of the user (fixed number of bytes), then the size of the message (eg: stored with an int32_t) and then the actual message.
Related
Please answers in yes or no. This will solve my doubt.
1. Is a post/get request sent from computer-1 to Computer-2 then first they have to make a socket connection?
2. When 2 computers connect with ssh then first they have to make a socket connection , then only then can talk to each other ?
The examples you give involve network connections and sockets are a common abstraction used when communicating over modern computer networks; however, other abstractions could be used. This is what Damien_The_Unbeliever is saying in the comments. For example, you could ask whether for loops are the only way to iterate over an array. The answer is the same: for loops are a common abstraction to loop over elements of an array, but there are other equivalent (in a machine-code sense) methods of doing so using other abstractions.
More fundamentally, computers can communicate with each other without using networks at all. You could have computers communicate over an interface consisting of webcams and monitors; sending is accomplished by putting something on the screen and receiving is accomplished by receiving the video feed. You could do the same with microphones and speakers. You could do the same with robotic arms, keyboards and mice. Two computers can communicate with each other using a human courier; my work and home computers do it regularly! Computers could write letters and mail them, deliver them or use carrier pigeons to send them to other computers designed to accept information in those formats.
Please answers in yes or no. This will solve my doubt.
[ok]
Is a post/get request sent from computer-1 to Computer-2 then first they have to make a socket connection?
In this case, Yes, but if request is going from browser then it do for you.You can see thr url for get and post have the port number in them. If not mentioned the default port is 80, in general. For example If you use WebSphere Application Server, the default port is 9081 or 80 if IBM HTTP Server is configured.
When 2 computers connect with ssh then first they have to make a socket connection , then only then can talk to each other ?
In this Case, again Yes, the port is 22 in ssh
I understand why a server would need sockets for incoming data, but I do not understand why it is necessary that a socket connecting to another computer needs a source port.
While others have mentioned the exact reason why, let me illustrate the point by giving you an example:
Say you want to ssh to your server. OK, you ssh in and do some stuff. Then you tail a log file. So now you don't have access to the console anymore. No problem you think, I'll ssh again...
With one port number, if you ssh again that second connection will be a mirror of the first since the server won't know that there are two connections (no source port number to tell the difference) so you're out of luck.
With two port numbers you can ssh a second time to get a second console.
Say you browse a website, say Stackoverflow. You're reading a question but you think you've seen it before. You open a new tab in your browser to stackoverflow to do a search.
With only one port number the server have no way of knowing which packet belongs to which socket on the client so opening a second page will not be possible (or worse, both pages receive mixed data from each other).
With two port numbers the server will see two different connections from the client and send the correct data to the correct tab.
So you need two port numbers for client to tell what data is coming from what server and for the server to tell what data is coming from which socket from the client.
A TCP connection is defined in terms of the source and destination IP addresses and port numbers.
Otherwise for example you could never distinguish between two connections to the same server from the same client host.
Check out this link:
http://compnetworking.about.com/od/basiccomputerarchitecture/g/computer-ports.htm
Ultimately, they allow different applications and services to share the same networking resources. For example, your browser probably uses port 80, but your email application may use port 25.
TCP communication is two-way. A segment being sent from the server, even if it is in response to a segment from the client, is an incoming segment as seen from the client. If a client opens multiple connections to the same port on the server (such as when you load multiple StackOverflow pages at once), both the server and the client need to be able to tell the TCP segments from the different connections apart; this is done by looking at the combination of source port and destination port.
As we know in any web application for a tab in a browser there is one process so we require an ip address and a port number to identify the process. As we know for every tab there is unique port number. So for every process there is unique process id. Also instead of using ip and port number combination can we use ip and process id combination in socket programming. And if so then how? And if not why? Please can you help me.. Sorry for the bad English
Can we use IP address and process id combination instead of IP address and port number?
No.
Why and why not?
Because they didn't define TCP/IP that way. It doesn't make sense. A remote computer doesn't have a way of discovering a process ID on another host. What it needs is a fixed number, i.e. a port number, which both hosts can implement.
As we know for every tab there is unique port number.
This is absolutely and definitely incorrect. 'We' don't 'know' any such thing.
As we know in any web application for a tab in a browser there is one process
That is not guaranteed. That is an implementation detail of the browser. It may or may not use a separate process for each tab.
so we require an ip address and a port number to identify the process.
No, you need an IP address and port to identify a given socket endpoint. A process can have more than one socket active.
As we know for every tab there is unique port number.
That is not guaranteed, either. HTTP is stateless, and connections are not guaranteed or required to stay connected between requests, especially for long periods of time. Say you open a tab and request a given website, leave the tab open for awhile, and then open a new tab to a different website. The previous connection(s) may have been closed while the tab sat idle, and those port(s) may be available for re-use in the new tab.
So for every process there is unique process id.
That is the only thing that is guaranteed in this situation. But remember that once a process ends, its process id can and will be re-used in a subsequent new process.
Also instead of using ip and port number combination can we use ip and process id combination in socket programming.
No. But on some platforms, such as Windows, there are APIs available to discover the process ID that owns a given socket, at least.
if not why?
Because that is not how sockets are designed to operate. A socket endpoint is identified by its protocol/IP/port tuple, and a socket connection is identified by the protocol/IP/port tuple of the two peers that are connected to each other. Remember that a socket connection can span across machine boundaries, but a process ID is only local to the machine it is running on.
This Morning I Booted my Computer and Had multiple applications needing an update. While I was waiting for the applications to update, a question came to mind which I thought I'd ask in here.
The question is How does each application known which internet data being retrieved is theirs?
The applications don't even care about it, they let the Kernel sort out that information.
When an application establishes a connection with a remote computer, the Kernel assigns that application a local port, which is a number among 0-65535. This port on the receiving end can either be requested by the application or the kernel will assign a random port. Generally there is only one application per port, however it is possible for multiple applications to receive the same data, though this is rare.
When a packet is received by the network interface, the kernel will sort the packet by its destination port. There will be a table in the kernel mapping ports to processes, and each application will receive the relevant data without caring about any other possible data that could be coming in the computer.
If you are a programmer, you can learn about all this stuff by reading about socket programming:
http://en.wikipedia.org/wiki/Network_socket
is a good place to start. You can also google "socket programming" with your preferred programming language to get an idea of how this is set up on the programming end.
I have been working on a local LAN service which uses a multicast port to coordinate several machines. Each machine listens on the multicast port for instructions, and when a certain instruction is received, will send messages directly to other machines.
In other words the multicast port is used to coordinate peer-to-peer UDP messaging.
In practice this works quite well but there is a lingering issue related to correctly setting up these peer-to-peer transmissions. Basically, each machine needs to announce on the multicast port its own IP address, so that other machines know where to send messages when they wish to start a P2P transmission.
I realize that in general the idea of identifying the local IP is not necessarily sensible, but I don't see any other way-- the local receiving IP must be announced one way or another. At least I am not working on the internet, so in general I won't need to worry about NATs, just need to identify the local LAN IP. (No more than 1 hop for the multicast packets is allowed.)
I wanted to, if possible, determine the IP passively, i.e., without sending any messages.
I have been using code that calls getifaddrs(), which returns a linked list of NICs on the machine, and I scan this list for non-zero IP addresses and choose the first one.
In general this has worked okay, but we have had issues where for example a machine with both a wired and wifi connection are active, it will identify the wrong one, and the only work-around we found was to turn off the wifi.
Now, I imagine that a more reliable solution would be to send a message to the multicast telling other machines to report back with the source address of the message; that might allow to identify which IP is actually visible to the other machines on the net. Alternatively maybe even just looking at the multicast loopback message would work.
What do you think, are there any passive solutions to identify which address to use? If not, what's the best active solution?
I'm using POSIX socket API from C. Must work on Linux, OS X, Windows. (For Windows I have been using GetAdapterAddresses().)
Your question about how to get the address so you can advertise it right is looking at it from the wrong side. It's a losing proposition to try to guess what your address is. Better for the other side to detect it itself.
When a listening machine receives a message, it is probably doing do using recvfrom(2). The fifth argument is a buffer into which the kernel will store the address of the peer, if the underlying protocol offers it. Since you are using IP/UDP, the buffer should get filled in with a sockaddr_in showing the IP address of the sender.
I'd use the address on the interface I use to send the announcement multicast message -- on the wired interface announce the wired address and on the wireless interface announce the wireless address.
When all the receivers live on the wired side, they will never see the message on the wireless network.
When there is a bridge between the wired and the wireless network, add a second step in discovery for round-trip time estimation, and include a unique host ID in the announcement packet, so multiple routes to the same host can be detected and the best one chosen.
Also, it may be a good idea to add a configuration option to limit the service to certain interfaces.