I have made a peer to peer program in TCP then merged to UDP. I would like to change it so you can send files, however UDP does not support this and TCP is slower than TCP. Due to the fact that these are the most common Data Transport Layers, I was curious to learn about any other layers that I do not know about.
So what other layers are there that would work with VB.net?
I would probably use HTTP for this.
The things you are thinking about inventing is already invented there.
This could be good starting points for your server side:
http://msdn.microsoft.com/en-us/library/system.net.httplistener(VS.80).aspx
And the client:
http://msdn.microsoft.com/en-us/library/system.net.webclient.aspx
Related
I have been playing around with OpenThead for about a month and I have set up two TI CC2538s in an OpenThread network, currently, I can send pings between them and modify the network parameters using the CLI, but they aren't capable of much else.
I would like to develop an application for them that is capable of transmitting some form of data using the OpenThread stack, maybe something simple at first like transmitting a block of text, however, I am not really sure where to start with this, are there any example applications that I could use as a starting point?
For application layers that sit directly on top of OpenThread, Nordic has released some examples in their nRF5 SDK for Thread.
Also note that Thread (and OpenThread) implement an IPv6 link capable of transporting vanilla IPv6 datagrams. As a result, you could run other transport protocols like TCP. However, UDP is often recommended due to relatively high loss rates and latency variance that is common to low-power, wireless mesh networks.
UDP has one good feature - it is connectionless. But it has many bad features - packets can be lost, arrive multiple times, there is no packet sequence - packet 2 can arrive faster than 1. How to keep good and remove bad?. Is there any good implementations that provide reliable transport protocol on top of udp so that we are still conectionless but without mentioned problems. One example of what can be done with it is mosh.
What you describe as bad isn't really bad depending on the context.
For example UDP is used a lot in realtime streaming, delivery confirmation and resending is useless in this context.
That being said there are e few implementations that you might want to look at:
ENet (http://enet.bespin.org/)
RUDP (https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol)
UDT (https://en.wikipedia.org/wiki/UDP-based_Data_Transfer_Protocol)
I work in embedded context:
CoAP (https://en.wikipedia.org/wiki/Constrained_Application_Protocol) also implements a lot of these features, so its worth a look.
What is your reason for not choosing TCP?
How can I use netty to build reliable UDP?
Modify netty's source code?
Or use netty as low level, and implement reliable at the application layer?
Thank you!
Best Regards!
It depends on your application's design. It is much easier to build a thin application layer (with simple data frame with sequence numbering, acknowledgement frame with received sequence number, and optional timer handlers to implement re-transmission) than modifying the Netty UDP transport source to add these things.
This approach might face some issues like, sending frames bigger thank IP frames, you have handle application PDU fragmentation, later you might have to keep adding more things to the layer. Any way I would do this only if TCP or SCTP (Netty 4.X supports SCTP) can not be used for the purpose.
I had a discussion with my manager, he said tcp is faster than http because of tcp is work on layer lower than http.
Then I remember about the OSI Model that I learnt in university, so I think what he meant is because http work on application layer but tcp work on transport layer (which is 2 layers belows) so is faster...
So my questions is:
Is lower layers works faster than upper layers is becasue there is less layers need to access when doing data transfers betweens two computers?
If so, that's mean when we use tcp (i.e with WCF), the commnicuation will be start at transport layers => down to physical layer => another computer's physical layer => up to transport layers? But I throught the data still need to be understand by the application, so it will still has to goes up to Application layer?
Thanks in advance.
There is always a layer above TCP. The question is really about how much overhead the stuff above TCP adds. HTTP is relatively chunky because each transmission requires a bunch of header cruft in both the request and the response. It also tends to be used in a stateless mode, whereby each request/response uses a separate TCP session. Keep-alives can ameliorate the session-per-request, but not the headers.
I noted the WCF tag, so I guess you're comparing NetTcp to for example BasicHttp. As #Marcelo Cantos pointed out, both drive on the TCP protocol.
Whereas the BasicHttpbinding uses HTTP for transport, a message is first encapsulated in XML (which is pretty verbose and data-eager) and then sent through HTTP, using lots of data for headers.
On the contrary, NetTcp uses a (proprietary?) protocol, where the message encoding and headers are specifically designed to decrease bandwidth usage.
In a common scenario you won't see any difference, but when dealing with lots of requests or larger amounts of data (especially binary data, which has to be encoded to fit in XML which increases its size), you might gain benefits by using NetTcp.
You are correct: TCP and HTTP are protocols that operate on different layers.
In general: in order for applications to utilize networking they need to operate at the application layer. The speed that any given protocol goes depends on the overhead it demands. HTTP typically operates over TCP, so it requires all of the overhead of TCP, all of the overhead of the layers under TCP, and all the overhead that HTTP requires itself (it has some rather large headers).
You're essentially comparing apples to oranges in comparing the speeds of TCP and HTTP. It makes more sense to compare TCP vs UDP vs other transport layer protocols -- and HTTP vs FTP vs other application layer protocols.
I typically use hardwired serial port connections between embedded devices for custom command/response/status protocols.
In this application I plan to use the microchip TCP/IP stack and Wi-Fi module with no OS to exchange short (<= 100 byte) commands and responses.
The stack is up and running on a microchip ethernet development kit and I am able to ping it from my desktop (not using the Wi-Fi module just yet).
I suppose I could hack into ping (microchip provides the c source for the stack) and add the messages I need to it, but I am looking for the correct/simplest/best method.
Correct / simplest / best aren't necessarily the same thing. But if I were you, I would consider using UDP instead of TCP.
UDP is a datagram protocol; TCP is stream-oriented and has a lot more overhead (and benefits that come with the overhead). But UDP more closely matches the current serial port byte-oriented (packet-oriented) approach you have today.
Chances are you have some higher-level protocol that receives/buffers/checksums/delimits/parses the data stream you receive from the UART. If you use UDP, you can mimic this nicely with a lean, lightweight UDP implementation. With UDP you just shoot out the bytes (packets) & cross your fingers that they got to the other end (a lot like serial).
TCP is heavier-weight connection-based protocol with built-in resending, acknowledgments, in-order delivery, timers, back-off algorithms, etc. On most embedded systems I've worked with using TCP (several different stacks), UDP is lighter-weight & outperforms TCP in terms of code size & throughput.
Also don't forget that TCP is used as the backbone of the internet; some packets pass through a dozen or more hops (routers/gateways) en route to the final destination. Lots of places for packets to get dropped, so TCP handles a lot of messy details transparently. I'd guess in your system/situation, we're talking about a LAN (everyone on the same wire) and transmission will be pretty reliable... thus the TCP overhead isn't really necessary.
There are times when the benefits of TCP justify the overhead, but from what you've written I think you should consider a basic UDP datagram set up. Just google "simple udp example" and you'll see the basic structure. For example, here is a simple UDP client/server example using just 43 lines (server) and 30 lines (client).
When you have a TCP/IP stack, it should provide a send() function to send some data messages.
Some small devices come only with a simple UDP/IP implementation, since this is a lot simpler. If you don't need the sequence control and reliability of TCP you could consider to use UDP to send short messages. This is much better to hack the ICMP messages.
But if you need the comfort and reliabilty of the TCP stream protocol, dont re-invent this on base of IUDP. Usually you can't do it better, more efficient and with less effort.