Reliable UDP

Question

How can I develop a Linux kernel module in order to make UDP reliable? This is my college assignment and I don't how to proceed. how to do change the default UDP behaviour in linux kernel by loading a new kernel module? and how to program such kernel module?

Answer 1

Overlay TCP on top of UDP, as TCP already does. 'Reliable UDP' is an oxymoron. It's not designed to be such.

Answer 2

Don't reinvent the wheel, it's already done for you. TCP.

Answer 3

You would need implement everything in TCP just use TCP.

Since you have to do it for homework.

You need to think about what reliable means. Also you need to decide if you need the packets in order or if out of order is ok. If out of order is ok you need to come up with an ACK, retransmit, and timeout scheme. Also you need to decide if you are going to handle packet fragmentation. If you can get away with it yo might want to limit the size of a packet to prevent fragmentation.

Answer 4

There actually is reliable UDP, it's called RUDP, and it was invented for Plan 9. However, there really is no point to this, just use TCP.

Edit: Also, UDT might be useful. It is based on UDP, but is reliable.

Answer 5

If for some reason you MUST use UDP (seriously, just use TCP) some quick and easy reliability features would be a presence heartbeat, acks, and xor'ed checksums.

Answer 6

If you absolutely need a message-based transport layer protocol where you can turn off some of the TCP reliability features like head-of-line blocking, check out SCTP. The API even has a "UDP mode" that masks the underlying connections.

It's still a work in progress, so you can't expect users to have it -- but if you only need it for computers you maintain, it should be fine. It's implemented in various flavors of unix, though FreeBSD is where most of the development work happens. YMMV.

Answer 7

Reliable UDP is not the same as just using TCP. There are a number of differences but the most predominant is that you are guaranteed to always receive an entire UDP message or not receive it at all. Whereas, it is not only possible but very common to receive partial TCP messages.

Since this is just a homework assignment I would suggest just implementing a single send message, wait for an ACK, send next message routine with a timeout. If the timeout kicks in then resend message some number of times before declaring a failure. Yes, this will be slower than necessary. There are lots of techniques to improve throughput, but for your assignment the odds are that you don't need to use them.

Answer 8

I use UDP a lot, and the main "reliability" issue I end up seeing is lost packets (particularly in fragmented IP packets). You could probably do %90 of what needs to be done by preventing fragmenting (add a layer that chops up datagrams into IP-sized chunks), and by having the recipeint detect and request resends for lost "chunks".

However, this kind of thing is really what TCP was invented for. UDP is best used for time-sensitive data that would be stale on a resend anyway.

There is a network topological solution. Just arrange things so that there can't be any collisions (the #1 source of lost packets on a LAN). Here's what we do where I work to make UDP reliable:

• Put one client and server on a dedicated ethernet link (perhaps a switch between them, but no other systems on their private LAN).
• Keep a strict client-server communications protocol on the UDP LAN. The server is never allowed to talk, except in response to the client.
• Turn off all exteranious networking garbage on that UDP link (Netbios, etc).
• Make ARP entries on both ends static (so ARP won't interfere once every 10 minutes).

Answer 9

If you want more information on how to modify the Linux Kernel, my first response is to google "linux kernel" and maybe even add "socket" to it. The Linux Kernel website looks like it might have some other leads for you to follow.

My suggestions are that

1) Look at how UDP is implemented in Linux
2) Look at how RUDP is implemented (as somebody already mentioned)
3) ... (you make magic happen here)
4) Profit! err... Finished Homework!

Answer 10

The techniques for reliable transmission of data are collectively known as "ARQ", which stands for Automatic Repeat reQuest.

It's too verbose a subject to explain here, but the wikipedia pages are a good place to start, but little more than that. I recommend you pick up one of the text books on computer networking (e.g. Tanenbaum or Kurose/Ross) and go from there. If you think it suffices for your assignment, implement basic stop-and-wait ARQ and forget about the more advanced ARQ schemes, they're a lot more work to build.

I have no experience developing Linux kernel modules, but if you go for one of the more advanced ARQ schemes I wouldn't be surprised if the implementation of the ARQ mechanism turns out to be more work than packing that as a kernel module.

Good luck with your assignment.

Answer 11

Possibly what you may be getting stuck on is the concept 'reliable'. Do you have a clear concept of what, exactly, in technical terms, you mean by that? (Or, more relevantly I suppose, what your instructor means by it.)

When you have a precise idea of what characteristics a protocol has to have for you to call it reliable, that's likely to provide directions for you to work in. Building to that as a minimal requirement, rather than getting lost in more fully-featured real-world implementations, may also make completing your homework more feasible.

Answer 12

I'm not sure that there is a simple way to modify the behaviour of the existing UDP code via a new module.

What would be simpler is to take the UDP code (net/ipv4/udp.c) and create a new module with a new IP protocol number, and modify this code to implement your reliable UDP protocol. You will need to rename all the external symbols so the names dont clash with the existing symbols, find out where it registers the protocol number (17) and change that, and then update the Makefile to build your new module and probably put an entry in Kconfig.

Have a look in /etc/protocols to see what protocol IDs are allocated already.

Edit: It looks like that udp.c cannot be built as a module. You will need to look at some of the other protocols (such as ipip.c or ip_gre.c) to see how to make your code into a module.

Answer 13

I think asking how to make UDP reliable may be approaching the question the wrong way. UDP is unreliable more or less by definition - ipso facto. You aren't going to get anywhere making the OS-side implementation of the protocol more "reliable."

A great many applications that use UDP use it because they need the low-overhead, low-latency nature of it much more than they need the precise reliability of TCP. But almost all of these applications still need some mechanism for verifying end-to-end receipt of certain types of messages, and perhaps even reassembly and/or initial handshaking. Think about SIP in VoIP telephony, for example; TCP's latent three-way handshake and very gradual congestion control aren't really acceptable for decent call setup time or QoS, but some way of acknowledging messages is definitely needed (that's what provisional responses are for, in SIP terminology). Or various protocols in use by online games -- same basic idea.

It is very likely that the real intent of the assignment - even if is not stated clearly - is not so much to make UDP reliable as to create a simple program that uses UDP and has some primitive reliability abstraction layer within its own communication scheme, encapsulated in UDP as it were.

Answer 14

To be honest I wonder if this is a trick question. It takes two parties to communicate and absolutely nothing you do can ensure the sender knows (or cares) that you want it to resend a packet unless you have already established a protocol to communicate this wish. If UDP itself can do this, I strongly suspect the kernel already supports it.

What you're left with is identifying and implementing a module that implements a new protocol. There's nothing wrong with that, others have already given you suggestions, and I'm sure that you can use the UDP implementation to handle the actual packet transport. But just remember that it's an implementation of a new protocol, not just twisting UDP a little to get new functionality in it.

Answer 15

Those who keep telling the poor guy to "just use TCP" ignore that there are good reasons why a reliable UDP implementation would be used over TCP - and it's not datagram semantics (which dead easy to layer on top of TCP)

A primary legit driver is connectionless communications to/between many nodes that could otherwise require carrying excessive connection multiplicity

This is often used for broadcast datafeeds, intra-cluster system software communications, etc.

Answer 16

P2engine is a flexible and efficient platform for making p2p system development easier. Reliable UDP, Message Transport , Message Dispatcher, Fast and Safe Signal/Slot...

http://sourceforge.net/projects/p2engine/