This is a broad question:
How do File descriptor, connection, socket, ip all relate to each other?
Is a file descriptor just a text file? And so when I make a connection to a server, does it mean the server and my computer basically create a file descriptor and we communicate through writing into the file?
Why servers have a limit of file descriptors? When a server opens up too many connections, it could fail with an error: too many files open. Is it because with each connection the server opens up a new text file?
An IP address is a "number" that identifies a machine in a network. So you can say "send this data to IP x.x.x.x" and the network knows which one is the destination machine. There are several ways to assign IP addresses to machines.
A connection is a conceptual link between two machines. It is conceptual because it is not necessary that the machines are directly wired to each other or anything: they are linked "through the network".
A socket is a programming interface that allows a programmer to manage connections, so the programmer can:
Establish (open) a new connection to another machine
Listen for incoming connections from other machines
Read data received through a connectino
Write data through the connection
Discard (close) the connection
A file descriptor is an element (typically a number) that allows the programmer to identify a "stream" of data: files on disk, sockets, pipes, named pipes... basically anything you can read / write bytes in a sequential manner. They are called file descriptors because initially they identified files only.
Related
Currently we receive on port 9020 from a client. That client uses port switching on their end and sometimes we wind up with multiple "Established" connections on the one port - all with different remote ports. We can manually end each established connection and our job will connect again after a few seconds. We can also run ENDTCPCNN for each remote port listed. We are looking for a way to programmatically see if there are multiple remote ports connected to the local port and if so end the established connections (while leaving the Listener running). Does anyone know of a way to get the information?
To answer your question, assuming you are on a supported version of the OS, take a look at the QSYS2.NETSTAT_INFO SQL view.
select local_port, remote_port, protocol, tcp_state, idle_time, network_connection_type
from qsys2.netstat_info
where local_port = 9020;
Otherwise, you'd need to use the List Network Connections and Retrieve Network Connection Data APIs yourself.
But are you sure you need to do this? Sounds like the client is leaving the connection open for re-use. That's a good thing for performance. You server code should be automatically timing out and closing idle connections.
I'm using ForcebindIP to point an app at a specific network adapter, like this:
forcebindip -i 192.168.0.5 MyCSharpApp.exe
This works fine and the app isn't aware (or doesn't access) any of the other network adapters on the PC.
Is it possible to restrict ForceBindIP to outbound traffic only leaving the app to receive data from any local network adapter? Or even to specify a network adapter for outbound and another for inbound traffic?
I can't find an extra startup parameter for ForceBindIP that does this.
I'd appreciate any help with this.
If I get your problem correctly, you want to bind your application to listen for packets on all available interfaces but return packets to only through one given interface. I also assume it's a server application and you don't have neiter source code nor control over its behaviour.
Disclosure: I do not know how ForceBindIP works internally, I'm basing my understanding of it on this passage from the website:
it will then inject a DLL (BindIP.dll) which loads WS2_32.DLL into memory and intercepts the bind(), connect(), sendto(), WSAConnect() and WSASendTo() functions, redirecting them to code in the DLL which verifies which interface they will be bound to and if not the one specified, (re)binds the socket
Problems to overcome
I don't believe your desired configuration is possible with just one application level DLL injector. I'll list a few issues that ForceBindIP will have to overcome to make it work:
to listen to a socket, application has to bind() it to a unique protocol-address-port combination first. An application can bind itself to either a specific address or a wildcard (i.e. listen on all interfaces). Apparently, one can bind to wildcard and specific address simultaneously as outlined in this SO question. This however will be two different sockets from the application standpoint. Therefore your application will have to know how to handle this sort of traffic.
When accepting client connection, accept() will create a new socket and parameters on that are managed by Windows, I don't believe there's an API to intercept binding here - by this time the connection is considered established.
Now imagine, we somehow got a magic socket. We can receive packets on one interface and send to another. The client (and all routing equipment on the way) will have to be aware that two packets originating from two different source IP addresses are actually part of the same connection and be able to assemble the TCP session (or correctly merge UDP streams).
You can have multiple gefault gateways with different priorities and rules (which is a whole different topic to explore) but as far as I'm aware that's not going to solve your particular issue: majority of routing protocols assume links are symmetric and expect packets to keep within same interface. There are special cases like asymmetric routing and network interface teaming but they have to be implemented on per-interface level.
One potential solution
One way to achieve what you're after (I don't know enough about your environment to claim it will work), will be to create a virtual interface, set it into yet another IP network, bind your application to it, then use firewall (to, say, allow multicast backets into the "virtual" network) and routing from that network to required default gateway with metric set to 1. I also suspect just any Windows will not be that flexible, so you might need like a Server Edition.
I am sorry this didn't turn out to be the ready-to-fly solution, I however am hoping this gives you more context to the problem you are facing and points you into other directions to explore.
You can use Set-NetAdapterAdvancedProperty command in Powershell to set the flow control of your specified adapter
To get the names and properties of all the network adapter :-
Get-NetAdapterAdvancedProperty -Name "*"
Suppose you want the network adapter named "Ethernet 2" to be only used to receive data from internet then type :-
Set-NetAdapterAdvancedProperty -Name "Ethernet 2" -DisplayName "Flow Control" -DisplayValue "Rx Enabled"
You can find more in :
https://learn.microsoft.com/en-us/powershell/module/netadapter/set-netadapteradvancedproperty?view=win10-ps
Microsoft winsock example has a usage in their example for limiting a socket to only send or receive mode. It might help.
https://learn.microsoft.com/en-us/windows/win32/winsock/complete-client-code
Outbount and Inbount limits are not imposed while binding. But latter or when connection is established.
Line of code pertaining to this in client code is toward the end.
// shutdown the connection since no more data will be sent
iResult = shutdown(ConnectSocket, SD_SEND);
Given file descriptors of two connected AF_UNIX sockets is it possible to ensure that they are indeed connected to the same peer?
A function like getpeername would do but it doesn't seem to support this family.
Regarding the definition of AF_UNIX socket, the socket is the method used by the processes of the local machine.
So, to get the peer(s) of a socket file, you just need to get the list of local processes that have opened the file descriptor.
You can do that using fuser command or lsof. Both unix command will give you the list of processes using the socket, and you may compare the result to status about your question.
While reading the FTP protocol specification from : (http://www.pcvr.nl/tcpip/ftp_file.htm). I came across this "FTP differs from the other applications that we've described because it uses two TCP connections to transfer a file". My question is, can FTP have multiple TCP connection for multiple parallel file transfer, for example can I transfer two files in parallel over two TCP connections, is this a matter of customization or standardization?
While it would be theoretically possible to make an FTP server support multiple, concurrent transfers, it's not supported by the RFC or any known implementation.
The block is a simple one in that the control connection, after receiving a transfer request, does not return a final status or accept new commands until the data transfer is completed. Thus, though you could queue up another transfer request it wouldn't actually be processed by the server until the current one completes.
If you want multiple file transfers, just log into the FTP server multiple times using different programs or command-line windows and have each initiate a transfer.
No it can't. FTP uses a control connection for sending commands and a data connection that exists for the duration of the file transfer or directory listing retrieval, that's it.
For more information you can consult RFC 959, which defines the specs of the FTP protocol.
I was reading tod lammales CCNA study guide 6th edition and stumbled upon this,
One thing to remember is that if multiple hosts are communication to
the server using HTTP, they must all use a different source port
number.That is how the web server keep the data separated at the
transport layer. page 337
Can this be true ? Because i always thought Ip and port number makes a unique endpoint at TCP layer, but according to this even for incoming connections from different source IPs, source port must be different ! appreciate your ideas.
No it isn't true. But what you said isn't true either. TCP connections are identified by the tuple {local address, local port, remote address, remote port}, not by any one of those, or two. What you have quoted, if accurate, would be (a) complete nonsense and (b) entirely unimplementable. How are all those clients going to co-ordinate amongst themselves to always use different source ports?