Is there any way to set keepalive for induvidual socket descriptor in vxworks? I read in some documents that "SOL_TCP" option in setsockopt function will do such favors in linux. Is such facility available in VxWorks too? If so please provide related details regarding the same, like what are the include file we need to include and how to use such option etc.
From the VxWorks "Library Reference" manual (can be download):
OPTIONS FOR STREAM SOCKETS
The following sections discuss the socket options available for stream (TCP) sockets.
SO_KEEPALIVE -- Detecting a Dead Connection
Specify the SO_KEEPALIVE option to make the transport protocol (TCP) initiate a timer to detect a dead connection:
setsockopt (sock, SOL_SOCKET, SO_KEEPALIVE, &optval, sizeof (optval));
This prevents an application from hanging on an invalid connection. The value at optval for this option is an integer (type int), either 1 (on) or 0 (off).
The integrity of a connection is verified by transmitting zero-length TCP segments triggered by a timer, to force a response from a peer node. If the peer does not respond after repeated transmissions of the KEEPALIVE segments, the connection is dropped, all protocol data structures are reclaimed, and processes sleeping on the connection are awakened with an ETIMEDOUT error.
The ETIMEDOUT timeout can happen in two ways. If the connection is not yet established, the KEEPALIVE timer expires after idling for TCPTV_KEEP_INIT. If the connection is established, the KEEPALIVE timer starts up when there is no traffic for TCPTV_KEEP_IDLE. If no response is received from the peer after sending the KEEPALIVE segment TCPTV_KEEPCNT times with interval TCPTV_KEEPINTVL, TCP assumes that the connection is invalid. The parameters TCPTV_KEEP_INIT, TCPTV_KEEP_IDLE, TCPTV_KEEPCNT, and TCPTV_KEEPINTVL are defined in the file target/h/net/tcp_timer.h.
IP_TCP_KEEPINTVL and also TCP_KEEPIDLE, TCP_KEEPCNT options supported by setsockopt after vxworks 6.8 version. In former releases of vxworks you can change these values globally and all the sockets created effected.
Below question is an answer for how will it be done.
How to set TCP keep alive interval for a specific socket fd (Not system wide) in VxWorks?
Related
I'm using RPC Pattern for processing my objects with RabbitMQ.
You suspect,I have an object, and I want to have that process finishes and After that send ack to RPC Client.
Ack as default has a timeout about 3 Minutes.
My process Take long time.
How can I change this timeout for ack of each objects or what I must be do for handling these like processess?
Modern versions of RabbitMQ have a delivery acknowledgement timeout:
In modern RabbitMQ versions, a timeout is enforced on consumer delivery acknowledgement. This helps detect buggy (stuck) consumers that never acknowledge deliveries. Such consumers can affect node's on disk data compaction and potentially drive nodes out of disk space.
If a consumer does not ack its delivery for more than the timeout value (30 minutes by default), its channel will be closed with a PRECONDITION_FAILED channel exception. The error will be logged by the node that the consumer was connected to.
Error message will be:
Channel error on connection <####> :
operation none caused a channel exception precondition_failed: consumer ack timed out on channel 1
Timeout by default is 30 minutes (1,800,000ms)note 1 and is configured by the consumer_timeout parameter in rabbitmq.conf.
note 1: Timeout was 15 minutes (900,000ms) before RabbitMQ 3.8.17.
if you run rabbitmq in docker, you can describe volume with file rabbitmq.conf, then create this file inside volume and set consumer_timeout
for example:
docker compose
version: "2.4"
services:
rabbitmq:
image: rabbitmq:3.9.13-management-alpine
network_mode: host
container_name: 'you name'
ports:
- 5672:5672
- 15672:15672 ----- if you use gui for rabbit
volumes:
- /etc/rabbitmq/rabbitmq.conf:/etc/rabbitmq/rabbitmq.conf
And you need create file
rabbitmq.conf
on you server by this way
/etc/rabbitmq/
documentation with params: https://github.com/rabbitmq/rabbitmq-server/blob/v3.8.x/deps/rabbit/docs/rabbitmq.conf.example
I am trying to create a SAP RFC connection to a new system.
AFAIK the firewall (in this case to port 3321) is open.
I get this message at the client:
RFC_COMMUNICATION_FAILURE (rc=1): key=RFC_COMMUNICATION_FAILURE, message=
LOCATION SAP-Gateway on host ax-swb-q06.prod.lokal / sapgw21
ERROR timeout during allocate
TIME Thu Jul 26 16:45:48 2018
RELEASE 753
COMPONENT SAP-Gateway
VERSION 2
RC 242
MODULE /bas/753_REL/src/krn/si/gw/gwr3cpic.c
LINE 2210
DETAIL no connect of TP sapdp21 from host 10.190.10.32 after 20 sec
COUNTER 3
[MSG: class=, type=, number=, v1-4:=;;;]
And this message on the SAP server
Any clue what needs to be done, to get RFC working?
With this little info no one can know what the issue is here.
But it is something related to your network and SAP system configuration.
I guess your firewall does some network address translation (NAT) and the new IP behind the firewall does not match anymore with the known one. SAP is doing some own IP / host name security checks.
If not already done, check with opening the ports 3221, 3321 and 4821 in the firewall. Also check the SAP gateway configuration which IP addresses and host names are configured to be valid ones for it (look at what is traced in the beginning of the gateway trace file dev_rd at ABAP side).
Also consider if maybe the usage of a SAProuter would be the better option for your needs.
it works in my case if ashost is the host name, and not an IP address!
Do not ask me why, but this fails:
Connection(user='x', passwd='...', ashost='10.190.10.32', sysnr='21', client='494')
But this works:
Connection(user='x', passwd='...', ashost='ax-swb-q06.prod.lokal', sysnr='21', client='494')
This is strange, since DNS resolution happens before TCP communication.
It seems that the ashost value gets used inside the connection. Strange. For most normal protocols (http, ftp, pop3, ...) this does not matter. Or you get at least a better error message.
I downloaded the stun client from http://www.stunprotocol.org/ and trying to figure out the NAT type by command stunclient --mode full stun.stunprotocol.org --verbosity 9 and I got the below response.
config.fBehaviorTest = true
config.fFilteringTest = true
config.timeoutSeconds = 0
config.uMaxAttempts = 0
config.addrServer = 52.86.10.164:3478
socketconfig.addrLocal = 0.0.0.0:0
Sending message to 52.86.10.164:3478
Got response (68 bytes) from 52.86.10.164:3478 on inter
Other address is 52.201.75.212:3479
Sending message to 52.201.75.212:3478
Got response (68 bytes) from 52.201.75.212:3478 on inte
Sending message to 52.201.75.212:3479
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Sending message to 52.201.75.212:3479
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Sending message to 52.86.10.164:3478
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Sending message to 52.86.10.164:3478
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Sending message to 52.86.10.164:3478
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Sending message to 52.86.10.164:3478
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Continuing to wait for response...
Binding test: success
Local address: 10.64.60.58:58841
Mapped address: 125.19.34.60:24604
Behavior test: fail
Filtering test: success
Nat filtering: Address and Port Dependent Filtering
I am working in a corporate and therefore for security reasons, NAT type "Address and Port Dependent Filtering" seems viable.
But as a general phenomenon, it seems to me that for peer to peer connections , most of the the time, NAT Type will be "Address and Port Dependent Filtering" and therefore turn server is required for any media communication.
However, searching on google for webrtc, it shows that 90% of peer to peer communication establishes through stun server itself( by hole punching etc). This means NAT type in that case is fully supported for establishing the connection.
Do experts have any opinions about the NAT type analytics to consider for peer to peer communication?
The stunclient program could use a bit more logging to indicate what it's doing. Since I know a little about the code, here's how I interpret it.
Stunclient does two different sets of tests. The first are the "mapping behavior" tests, which is the most important for understand how your NAT/Firewall will impact P2P connectivity. The other set are the "filtering tests" that are an indicator of how "open" your NAT is with regards to receiving traffic from other IP/port combinations.
Your behavior test "failed". What this likely means, based on your log output is this:
Test 1: Pick a random port, 58841, in this case. From this local port, do a basic binding test to stun.stunprotocol.org:3478. This is where the client receives a response where the server indicates the mapped address (125.19.34.60:24604) and that the stun alternate IP for subsequent behavior and filtering tests is at 52.201.75.212.
Test 2: Same local port, 58851. Send a binding request to the alternate IP and primary port (52.201.75.212:3478). In your case, it appears that the response that came back was likely a different ip or port. And in thist case "test 3" was required.
Test 3: Same local port, 58851. Send a binding request to the alternate ip and alternate port (52.201.75.212:3479) so it can distinguish between between "address dependent" vs "address and port dependent mappings". And this is the interesting part - you never got a response. Despite being able to communicate with both IP addresses on port 3478. This is why the test came back as failed.
Could be one of two things:
a) Your NAT/Firewall actually is open for port 3478, but not 3479. Do this from the command line to detect
stunclient 52.201.75.212 3479
And if that succeeds in getting a mapped address, then immediately do this:
stunclient 52.86.10.164 3478
Try other combinations of those two ip address and ports. The resulting behavior could mean the following
b) Your NAT/Firewall declines to port map when both the remove ip and port have changed. That means your network environment is even more restrictive that an "Address and Port dependent mapping" NAT. More commonly known as a symmetric NAT.
As for the filtering tests, just ignore this result. The filtering tests try to detect if you can send to one ip:port, but receive from a different ip or port. 99% of the time NATs disallow this. So the result almost always results in "Address and Port Dependent Filtering". The filtering test result is not very indicative of how your NAT will succeed in P2P connectivity.
And just because your enterprise network is very restrictive, it doesn't mean it's impossible for you to communicate with a peer on another network. If he has a more well behaved NAT with Endpoint Independent Mapping, then there's still a chance P2P connectivity will succeed.
I haven't kept up with NAT trends in recent yearas, but 80-90% of connections succeeding with STUN alone sounds right. The rest will need a relay solution such as TURN.
I imagine, you want to communicate between p2p in all possible scenarios (including symmetry NAT).
My suggestion: Try using webRTC and use stun and turn servers in ice server list. this will give you range of ICE candidates and webRTC will take care of connecting to best possible candidates.
this should save you from your NAT type concerns.
I am running ActiveMQ 5.9.0 release on my local machine for dev purposes (Windows 7). I am using AMQP as the protocol and Apache qpid as the client to consume messages (publish subscribe) from activeMQ broker (AMQP 1.0 protocol).
Although I have commented out all the protocols except amqp in activemq.xml, still periodically I am seeing the below message in broker log (standard out):
WARN: Transport Connect to tcp://<ip> failed: java.net.SocketException: Connection reset
I did try to "uncomment" the openwire protocl definition in activemq.xml and append transport.useInactivityMonitor=false (based on googling around):
I still cannot get warning messages to disappear.
I haven't used it myself. But the amqp protocol is using the tcp transport under the covers. Use of the protocol is documented here. You can configure it to use nio as well. It is hardcoded to have useInactivityMonitor=false. You can modify the transport options on the amqp transport by setting those options in the connect uri. For example:
<transportConnectors>
<transportConnector name="amqp" uri="amqp://0.0.0.0:5672?transport.keepAlive=true"/>
</transportConnectors>
The tcp transport options are documented here.
I sent messages through smpp connection (using selenium SmppSim) from Kannel and it worked.
But somehow when I try to receive messages or in other words when I try to send messages from SmppSim It doesn't work. The MO messages of the SmppSim queue into the MO-queue.
I tried these things.
Used same port for send and receive (Kannel/SmppSim).
Used different ports for send and receive (Kannel/SmppSim).
Two groups for same smsc-smpp for send and receive. (It may be wrong)
Now I'm using port 2775 for send and port 2776 for receive.
#kannel.conf
group=smsc
smsc=smpp
....
port = 2775
receive-port = 2776
transceiver-mode = true
....
In SmppSim
#smppsim.props
SMPP_PORT=2775
....
SYSTEM_IDS=smppclient
PASSWORDS=password
OUTBIND_ENABLED=true
OUTBIND_ESME_IP_ADDRESS=127.0.0.1
OUTBIND_ESME_PORT=2776
OUTBIND_ESME_SYSTEMID=smppclient
OUTBIND_ESME_PASSWORD=password
....
When I run the bearerbox, it shows like below. (sms send is working)
....
connect failed
System error 111: Connection refused
ERROR: error connecting to server `localhost' at port `2776'
SMPP[SMPPSim]: Couldn't connect to server.
SMPP[SMPPSim]: Couldn't connect to SMS center (retrying in 10 seconds).
....
How do I configure this?
Thank you!
Please read SMPP v3.4 specification, part 2.2.1.
The purpose of the outbind operation is to allow the SMSC signal an ESME to originate a
bind_receiver request to the SMSC.
So it's used for SMSC (SMPPSim) to connect to ESME (Kannel) and request for callback connection.
However you can run few SMPPSim instances listening on different ports. Each instance should use own configuration file this case.