I am coding a stop and wait UDP file transfer.
Everytime i send a packet, ill start a timeout timer and wait for acks. If i recv an ack, ill transmit the next packet. If i recv a nack or did not recv acks, once my timeout expires, ill retransfer the packet.
For the receivers end, whenever i recv a packet, ill transmit a ack when checksum and seq number tallies. Else a nack.
This is my school assignment, to code a udp file transfer with error detection.
So dont ask me to use tcp.
The problem is when i want to end the connection. Once the last packet has been sent, ill now send a EOF message to the receiver, signalling the end of file transfer. So i send the EOF message, and start the timer. The reciver, receives the EOF message, sends back an ACK message and shutsdown. However, if this ACK message gets discarded, the sender is gonna timeout and will repeatedly resend the EOF message. How do i go about preventing this?
Related
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.
JKJS
"Client finished message is encryption of all handshake messages".
But it is not clear:
1)Does it contain only handshake messages sent by client?
2)Does it contain only handshake messages received from server?
3)Or does it contain both of above?
4)Does handshake messages contain 'change cipher spec' message?
Please help me.
JKJS
Finished Message will contain the Handshake Messages sent from both the Server and Client. It will not contain the Change Cipher Spec Message as it is not considered as part of Handshake Messages.
The below paragraph in RFC 2246 explains it well:
The hash contained in finished messages sent by the server incorporate Sender.server; those sent by the client incorporate Sender.client. The value handshake_messages includes all handshake messages starting at client hello up to, but not including, this finished message. This may be different from handshake_messages in Section 7.4.8 because it would include the certificate verify message (if sent). Also, the handshake_messages for the finished message sent by the client will be different from that for the finished message sent by the server, because the one which is sent second will include the prior one.
Note: Change cipher spec messages, alerts and any other record types are not handshake messages and are not included in the hash computations. Also, Hello Request messages are omitted from handshake hashes.
I am attempting to create an inbound Mule endpoint that will receive Syslog messages from a remote server. The messages are recieved on port 514 using UDP packets.
As I've seen no built-in Mule support for syslog packets, I've tried to start dealing with this by creating a simple UDP connector on that port to receive the actual messages. However, when I raise the endpoint, I see no such messages received (outputed the data to stdio in order to check). When I do send "normal" UDP messages, they do come up on that endpoint. Additionally, I Installed a syslog server and verified that the syslog messages are indeed being received to my host computer.
My question is: how can I go about setting up that endpoint to receive syslog messages? Right now I'm working with this simple configuration:
<udp:inbound-endpoint host="localhost" port="514" exchange-pattern="one-way"/>
<stdio:outbound-endpoint system="OUT"/>
Your inbound endpoint looks correct. It should receive a mule message for each UDP packet received by that endpoint. The message's payload will be a byte array containing the packet's contents. You can dump each one with the following syntax:
<udp:inbound-endpoint host="localhost" port="514" exchange-pattern="one-way"/>
<logger level="WARN"/> <!-- dumps the message metadata -->
<logger level="WARN" message="[#payload:]"/> <!-- dumps the message payload-->
You'll see the payload being a byte array. To process it as a SYSLOG message, you'll need to write (or call) some Java code which understands the SYSLOG packet format.
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.
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?