Currently I need to implement socks client. According RFC, Socks protocol has two main commands: CONNECT and BIND. CONNECT is used to forward an outbound connection from socks' client to desired Server. BIND is used to forward an inbound connection from desired Server to socks' client.
My client work as follows:
Firstly It makes connection to socks Server, let us call it a "client connection".
After that it issues commands.
I have some misunderstanding with a "client connection" utilisation. Hence, I have the following questions:
A "client connection" could be used only for one CONNECTION command, is that right ? So for each desired communication I need to create a new "client connection" and after that issue command CONNECT.
For BINDing, firstly, i need to issue CONNECT and after issue command BIND. These commands must be issued in a one "client connection", am I right ?
How many inbound connections socks server could receive on BIND socket ? Only one ?
How traffic flows in case of BIND is used ? We have a "client connection" to socks server. For the "client connection" socks server has one connection to desired server and one incoming connection from desired server. Hence, socks server could receive data from two connections. How this traffic is mixed to the "client connection"?
Yes.
No. BIND is separate from CONNECT. It is for when you want to listen, so you tell the server to listen on your behalf and tell him what port you're listening on.
Pass.
There is only one connection between the client and the SOCKS server. Everything arriving from the client is sent to the 'desired server'. Everything arriving from the 'desired server' is sent to the client. There is nothing to mix. You wouldn't want the client's sends to be sent back to him, would you?
Related
I have multiple devices sending messages to a mosquito broker. I would like to manage a kind of device revocation so that when a device is revoked, I want the mosquito broker to automatically close the connection for this specific device.
Is there any command or way to ask the broker to explicitly close a connection to a specific client?
Thanks in advance,
hak
I do not think you can kick an already connected client.
But what you can do if using the Authentication Plugin (either a 3rd party or the included dynamic security plugin) to change the ACL that the user can publish/subscribe to which should effectively stop the client sending or receiving any messages and when it next tries to connect it will not be allowed.
I have been able to set up a wireless mesh network using batman-adv running on a few Raspberry Pis. The Pis are able to detect each other on the mesh, communicate between each other, and share an internet connection if any Pi on the network is acting as a gateway.
The problem I am facing is that if multiple gateways exist on the network, the clients (devices which are receiving the internet connection by the gateway) will never switch to getting their internet connection from any other gateway than the one they initially obtained it from, even if the routing algorithm detects that they have a better connection to another gateway.
Each gateway is running a DHCP server to assign IP addresses to the clients accessing the internet through them. The DHCP server I am using is dnsmasq.
The expected behaviour is either:
the clients send a DHCP request to the gateway capable of providing the better connection and end their lease with their current DHCP server, or
the clients keep their assigned IP from the DHCP server and (magically?) start accessing the internet through the gateway capable of providing the better connection.
Neither of these scenarios are happening. If for whatever reason the gateway providing the internet to a client drops, the client will not attempt to create a new connection until the DHCP lease times out. However this is contradictory to what is claimed on the wiki for this package: https://www.open-mesh.org/projects/batman-adv/wiki/Gateways
Please advise on how to configure this mesh network so that either one of the expected behaviours will happen.
This is exactly the expected behavior at the IP layer.
If a DHCP server provides a default gateway, that gateway remains in place for the life of the lease. The DHCP client, by design, cannot definitively determine if the default gateway is down.
DHCP is a poll-based protocol; a DHCP server cannot proactively change the parameters of a lease until the DHCP client requests an update. The instructions in the link of your question indicates that (emphasis added):
To inform clients possessing a valid DHCP lease about a gateway
change (the link quality to the gateway could have dropped or the
client is roaming around) batman-adv will also inspect incoming DHCP
renewal packets. If their destination is not the currently selected
gateway and below a certain TQ threshold (currently defaulting to a TQ
of 50), the DHCP renewal packet is not forwarded, thereby forcing the
client to request a new DHCP lease from a better-connected gateway.
Note that the change happens by inspecting incoming renewal packets. Due to the nature of DHCP, you are stuck waiting for a lease renewal request to update the gateway.
You can set low lease times to increase the polling rate, but if you need real-time reaction to failed gateways, you will need to employ an actual routing protocol.
I'm trying to create a HTTP(s) proxy server that will act like this:
Browser configured to use proxy on 127.0.0.1:1080. On this port, I need to have a server (TIdTCPServer?) that will pass data coming to a client, that is connected on this same server (maybe into another port to make things easier). The client need to be connected, and not serving connection because of possible NAT restrictions.
The idea is that the client will execute the requests and send back to the server, which should send to the browser.
Browser > connect to local server > send to client connected which make the request
I thought about IdHTTPProxy, but no idea on how to pass request to a client, and client execute, gets back the data to the server / browser.
I read about TIdMappedPortTCP, but looks like this should connect into another host/port, and in my case the client can't receive connections.
I noticed that when an MQTT Client with the same Client ID as another MQTT Client already connected to Solace, the second client will get "Not authorized to connect (5)" error message. When I tried the same scenario but connect to a different Solace appliance, the second client succeeded in connecting but the first client was disconnected forcefully by Solace. I checked the settings in both appliances but could not find any settings that lead to the different behaviour. Can anyone advise?
When a new client connects to a Solace appliance, and that client uses the same client name as an existing, connected client, you can configure the appliance to either:
reject the new duplicate client’s connection attempt
disconnect the existing client and connect the new, duplicate client
By default, the replacement of duplicate client connections during authentication is enabled on the appliance. To disable the replacement of duplicate client connections during authentication, use the following CONFIG command:
solace(config)# authentication
solace(config-auth)# no replace-duplicate-client-connections
If you are using SolAdmin to manage the appliance, you can change this property by navigating to the User Management tab, and selecting User Authentication from the Select View box. From the box at the right side of the Element Details area, select Manage Global Authentication, and click Execute Task. In the dialog box that appears, you can select or clear the Replace Duplicate Client Connections check box.
MQTT Broker can disconnect the existing client if the following condition is came up.
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718090
If the ClientId represents a Client already connected to the Server then the Server MUST disconnect the existing Client
[MQTT-3.1.4-2].
At this time, can broker send any specific message excluding "DISCONNECT" to client before server disconnect the existing client ?
Most brokers are going to follow the spec, if you want one to do something different then you will have to either write your own or modify one of the open source versions.