I need to create a program that sends messages, using SCTP, from host A to host B.
The problem is... I don't know how do run this program. How can I, using language C, send messages from one host to another.
Any vague answer is welcomed.
SCTP is a transport layer protocol, and the operating system has built-in transport layer protocols, including SCTP and you get to choose what protocol it uses.
But I think here is what you're looking for: http://simplestcodings.blogspot.com/2010/08/sctp-server-client-implementation-in-c.html
a demo implementation of SCTP above tcp/ip.
Related
I am studding the MQTT & TCP/IP protocol.
Since i'm able to know that, MQTT is based on the TCP so as the TCP/IP
& we refer MQTT though we have the TCP/IP Protocol.
Why don't we use TCP/IP instead of MQTT?
Is there any advantages of MQTT that makes it better solution than the TCP/IP protocol?
Which is more reliable & required less no of data packet to form a communication?
(Note : TCP/IP in the sense forming a network between 2 devices using normal TCP/IP protocol as in GSM modems "connect > transfer data > disconnect")
Is there any advantages of MQTT that makes it better solution than the TCP/IP protocol?
Yes, it offers things TCP doesn't offer, namely an application layer protocol. Other examples of such protocols are FTP, HTTP, SMTP.
You're asking the wrong question. IP makes sure you can send data to another machine, TCP makes sure this data is received in-order and acknowledged, and application-level protocols make sure you can make sense of the data you receive.
Without an application level protocol, you have no meaningful communication. Where each sockets programming example begins with "WriteLine" and "ReadLine" text message exchanges, that in itself is (albeit a very rudimentary) application level protocol, namely "client and server exchange text messages ending in a newline".
So, no, you cannot use TCP/IP without an application level protocol, because as soon as you start writing a program sending and/or receiving data, you have at that moment defined an application level protocol.
With its own problems. And that's why you shouldn't invent your own protocol, but use existing ones. Pick the one that suits your needs. Do you need to publish or subscribe messages to some broker, use MQTT.
Unless you know very well what you're doing, don't invent your own.
The benefits of using MQTT over TCP/IP far outweighs the data overhead it introduces. Also, MQTT was devised to solve a specific problem of getting sensor data from a remote system which could not be connected to the consumer of the sensor data all the time.
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 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.
Could i inject packets to Linux TCP stack without modifying the ethernet driver? Could i do this with using a library or sth ?
Thank you,
If by 'inject packets to Linux TCP stack' you mean send some data that the Linux kernel will treat as a frame coming from an Ethernet interface then you can use a 'tap' device. If an IP packet (layer 3) is good enough, then use a 'tun' device.
http://en.wikipedia.org/wiki/TUN/TAP
http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/networking/tuntap.txt
Libnet
Libnet is a generic networking API that provides access to several protocols. It is not designed as a 'all in one' solution to networking. Currently many features that are common in some network protocols are not available with Libnet, such as streaming via TCP/IP. We feel that Libnet should not provide specific features that are possible in other protocols. If we restrict Libnet to the minimal needed to communicate (datagram/packets) then this allows it to support more interfaces.
Otherwise, if you're just wondering about injecting hand-crafted packets into the network, read the man pages and look for online help with raw sockets. Some good places to start are man 7 raw, man packet, and there are some ok tutorials at security-freak.net, though the code there is not written particularly well for my tastes.