Using the SNMP4J library I am able to successfully retrieve information from multiple agents using SNMP over UDP. I am running into a situation where I need to retrieve information from an agent using SNMP over TCP. The SNMP4J library provides a DefaultTcpTransportMapping class to do this and I believe I've implemented it appropriately. Using Wireshark, I see response packets being returned from the agent running SNMP over TCP but I am getting null response PDUs. What other considerations do I need to address when implementing SNMP over TCP instead of UDP? Any help is greatly appreciated!
After a discussion with the board's manufacturer we've learned that the model for communication is SNMP over PMPP over TCP and I'm working on a custom SNMP4J transport to handle this model.
try to increase timeout value, TCP is slower than udp
UserTarget target = new UserTarget();
target.setTimeout(timeoutInMillis);
Related
I looking for an example of SNMP running in a protocol different than UDP. I need to argue with a professor who said that it's only possible to run SNMP over UDP. Anyone knows how it works in ATM? In my mind SNMP is a layer 7 protocol and doesn't matter what protocol is used for transport, but I only found references to UDP. Please post the references.
SNMP of course can go over other protocols than UDP. For example, RFC 3430 defines SNMP over TCP,
https://www.rfc-editor.org/rfc/rfc3430
However, the widely used SNMP implementation is still UDP only in most cases, so rarely you see an application on TCP or other protocols (I knew some internal usage in Cisco).
Well, an argument is not really suggested, and hope you chat in a good manner with your professor.
From RFC 1157 'A Simple Network Management Protocol (SNMP)' #4:
Protocol Specification
The network management protocol is an application protocol by which
the variables of an agent's MIB may be inspected or altered.
Communication among protocol entities is accomplished by the exchange
of messages, each of which is entirely and independently represented
within a single UDP datagram using the basic encoding rules of ASN.1
(as discussed in Section 3.2.2). A message consists of a version
identifier, an SNMP community name, and a protocol data unit (PDU).
A protocol entity receives messages at UDP port 161 on the host with
which it is associated for all messages except for those which report
traps (i.e., all messages except those which contain the Trap-PDU).
Messages which report traps should be received on UDP port 162 for
further processing.
If so, do you know examples of what can go wrong in a non-TCP network?
Learning about MQTT I came across several mentions of the fact that MQTT relies on TCP/IP stack. For example, from mqtt.org:
MQTT for Sensor Networks is aimed at embedded devices on non-TCP/IP
networks, whereas MQTT itself explicitly expects a TCP/IP stack.
But if you read the reference documents, you won't finding anything like that. Moreover, there's QoS field that can be used for reliable delivery and whose values other than 0 are essentially useless in TCP/IP networks. Right now I see nothing that would prevent me from establishing an MQTT connection using UNIX pipe, domain or UDP socket rather than TCP socket.
MQTT just needs a delivery that is ordered and reliable, it doesn't have to be TCP. SCTP works just fine, for example, but UDP doesn't because there is no way to guarantee your large PUBLISH packet made up of multiple UDP packets will arrive in order and complete.
With regards TCP reliability, in theory what you are saying is true, but in practice when an application calls write() and receives a successful return, it can't guarantee when the data has actually made it out of the computer to the remote host. All write() (or send()) does is copy the data to the kernel buffers, at which point you have no further control.
The only way to be sure that a message reaches the remote host at the application level is to have the remote host reply.
MQTT-SN (for sensor Network ) is the solution for the problem that MQTT was having while running over TCP/IP .
There is a concept of MQTT gateway which is brought in in for MQTT-SN which helps in bringing non-TCP / IP implementation.
http://emqttd-docs.readthedocs.io/en/latest/mqtt-sn.html
I'm currently developping a highly responsive game in python using client-server model. The speed of the data exchanges between the client and the server needs to be very fast.
Is it possible to make both, udp and tcp connections ? Udp would be used only during the game. And Tcp will be used for more reliability-needed messages like connection, name changes, chat,...
Is it also a good way of thinking ? Or should i use only UDP ?
Yes, this can be a good idea. With UDP, a single lost packet does not stall the entire stream. On the other hand you need retry and congestion control.
I'd try to send messages using UDP and if no confirmation arrives within a short amount of time re-send them on a TCP connection that has been kept open. That should move 99% of the load to UDP and use TCP for congestion control and reliability.
The H2O database does it that way.
You can bind your UDP and TCP connections on different ports or even on the same port. As for which to use, it is up to you. Try both out and if TCP is too slow or UDP is too unreliable then you always have the option to switch.
You can also use a 3rd-party library that builds reliability layer over UDP and specify required reliability per packet. As an example you can check Raknet.
I have a question concerning tcp packet sniffing with golang.
We have written a small tool which captures all incoming TCP packets comming from a fibre Tap.
The current implementation uses a libpcap wrapper under Linux. We need to port this tool to Windows. Of course, it is not possible at the moment.
So my question is, is there a cross platform solution for sniffing packets? We only need TCP packets, IP headers , no Ethernet Data and not all features of libpcap.
If there is no cross platform solution, two Code implementation would be ok, too. I know one can use raw sockets under Linux (and with some limitations under Windows). Does Golang support raw sockets and is there an example implementation for sniffing packets with sockets?
Tanks!! :-)
You should be able to use the ipv4 package from go.net.
Package ipv4 implements IP-level socket options for the Internet Protocol version 4.
The ipv4.RawConn type and it's associated methods should work cross-platform.
A RawConn represents a packet network endpoint that uses the IPv4 transport. It is used to control several IP-level socket options including IPv4 header manipulation. It also provides datagram based network I/O methods specific to the IPv4 and higher layer protocols that handle IPv4 datagram directly such as OSPF, GRE.
There is also an equivalent package for ipv6.
Take a look at https://code.google.com/p/gopacket/ since it supports pcap (requires cgo for this) and can decode a number of protocols including tcp/ip.
I'm trying to send large files using UDP Adobe air to CPP. While transferring large files some packets are missing. How can I retrieve the missing packets data? I'm first of all connecting client(air) with server(cpp) using tcp. After connection establishment I'm starting file transfer. I am planning to get the file missing data using tcp and then resending the missing packets using tcp. Can anybody tell me how can i come to know which packets are missing while transferring. Thank you.
Can you please clarify what is happening? You say you are sending files over UDP yet connecting to the sever with TCP - the two protocols are mutually exclusive over a single connection.
UDP does not provide any mechanism for detecting packet loss (that's what TCP is for) so by default you won't be able to work out whether packets have been lost.
You should use TCP for sending files as it manages sending/resending packets for you.
As stated in the Air ServerSocket documentation (http://help.adobe.com/en_US/air/reference/html/flash/net/ServerSocket.html):
All packets [sent over TCP] are guaranteed to arrive (within reason) — any lost packets are retransmitted. In general, the TCP protocol manages the available network bandwidth better than the UDP protocol. Most AIR applications that require socket communications should use the ServerSocket and Socket classes [TCP] rather than the DatagramSocket class [UDP].
See this page for more information on the Air networking classes:
http://help.adobe.com/en_US/air/html/dev/WSb2ba3b1aad8a27b0-181c51321220efd9d1c-8000.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7cfb
my guess, tcp is slower because it does a resend when a packet gets lost. so that's probably why it's slower. but on the other hand, checking which packets get lost and re-send them by udp will also take longer ...
i would go for TCP instead of UDP
Like Sly says, udp seems the wrong tool to use here