Develop Reference

Is there any python library that abstracts IP based transport -- TCP, UDP, SCTP, TLS etc.?

Recently I became interested in DIAMETER protocol defined by [RFC 6733][1]. Since I am learning Python, I thought that it might be interesting to see if I could use any DIAMETER Python library. I did find [one][2], but it appears to be no longer maintained. So I got the highly ambitious idea of trying to build one, at least something that is skeletal, that could be extended to have richer DIAMETER signaling capabilities.
Since I had also come across twisted matrix a while back, I tried to check it's documentation to see if has support for all types of transport that DIAMETER protocol could be supported on, but apart from TCP, UDP (and also TLS), I din't find mention of rest, i.e.
SCTP/IP
SCTP/UDP
DTLS/SCTP
So was wondering if there is any other library that could be used, or should I expect to have to hand-roll this ? Extending twisted, is beyond me at this step.
[1]: https://www.rfc-editor.org/rfc/rfc6733
[2]: http://i1.dk/PythonDiameter/

I don't know it this one is still supported (last update in december 2014)
http://sourceforge.net/projects/pyprotosim/
It does radius, diameter, dhcp, ldap, EAP calculations
You haven't chosen the easiest protocol. A lot of providers have their own AVPs, and sometimes they even use standard numbers for theirs.
You can also write your own lib to parse DIAMETER, it's not that hard, you just need time (a lot) and good documentation (or experts).
If the one I did had not been developed during my work, I could have shared it, but I can't.

If you were going to roll your own, you can do this with Twisted by using the IFileDescriptor (and related) interface(s). Make an SCTP socket, wrap an IFileDescriptor around it that returns its fileno, then implement IReadDescriptor.doRead to call sctp_sendmsg and IWriteDescriptor.doWrite to call sctp_recvmsg. Now you have an SCTP transport. You can implement it to call methods on whatever SCTP protocol interface that is appropriate to the protocol. I don't know enough about SCTP to say what methods that protocol interface should have, unfortunately.

Serverless communication between network nodes in python

I am not sure if this question belongs here as it may be a little to broad. If so, I apologize. Anyway, I am planning to start a project in python and I am trying to figure out how best to implement it, or if it is even possible in any practical way. The system will consist of several "nodes" that are essentially python scripts that translate other protocols for talking to different kinds of hardware related to i/o, relays to control stuff, inputs to measure things, rfid-readers etc, to a common protocol for my system. I am no programming or network expert, but this part I can handle, I have a module from an old alarm system that uses rs-485 that I can sucessfully control and read. I want to get the nodes talking to eachother over the network so I can distribute them to different locations (on the same subnet for now). The obvious way would be to use a server that they all connect to so they can be polled and get orders to flip outputs or do something else. This should not be too hard using twisted or something like it.
The problem with this is that if this server for some reason stops working, everything else does too. I guess what I would like is some kind of serverless communication, that has no single point of failure besides the network itself. Message brokers all seem to require some kind of server, and I can not really find anything else that seems suitable for this. All nodes must know the status of all other nodes as I will need to be able to make functions based on the status of things connected to other nodes, such as, do not open this door if that door is already open. Maybe this could be done by multicast or broadcast, but that seems a bit insecure and just not right. One way I thought of could be to somehow appoint one of the nodes to accept connections from the other nodes and act as a message router and arrange for some kind of backup so that if this node crashes or goes away, another predetermined node takes over and the other nodes connect to it instead. This seems complicated and I am not sure this is any better than just using a message broker.
As I said, I am not sure this is an appropriate question here but if anyone could give me a hint to how this could be done or if there is something that does something similar to this that I can study. If I am beeing stupid, please let me know that too :)

There are messaging systems that don't require a central message broker. You might start by looking at ZeroMQ.

I ended up making my own serverless messaging system in python. It is not ready and the code is a mess, but it works. It has autodiscovery of nodes, sharing of channels and topics, and the features that I needed. If anyone is interested in using it or wants to help, it is here:
https://bitbucket.org/ssspeq/connection-manager

Why is there a need for Twisted?

I have been playing around with the twisted framework for about a week now(more because of curiosity rather than having to use it) and its been a lot of fun doing event driven asynchronous network programming.
However, there is something that I fail to understand. The twisted documentation starts off with
Twisted is a framework designed to be very flexible and let you write powerful servers.
My doubt is :- Why do we need such an event-driven library to write powerful servers when there are already very efficient implementations of various servers out there?
Surely, there must have been more than a couple of concrete implementations which the twisted developers had in mind while writing this event-driven I\O library. What are those? Why exactly was twisted made?

In a comment on another answer, you say "Every library is supposed to have ...". "Supposed" by whom? Having use-cases is certainly a nice way to nail down your requirements, but it's not the only way. It also doesn't make sense to talk about the use-cases for all of Twisted at once. There is no use case that justifies every single API in Twisted. There are hundreds or thousands of different use cases, each which justifies a lesser or greater subdivision of Twisted. These came and went over the years of Twisted's development, and no attempt has been made to keep a list of them. I can say that I worked on part of Twisted Names so that I would have a topic for a paper I was presenting at the time. I implemented the vt102 parser in Twisted Conch because I am obsessed with terminals and wanted a fun project involving them. And I implemented the IMAP4 support in Twisted Mail because I worked at a company developing a mail server which required tighter control over the mail store than any other IMAP4 server at the time offered.
So, as you can see, different parts of Twisted were written for widely differing reasons (and I've only given examples of my own reasons, not the reasons of any other developers).
The initial reason for a program being written often doesn't matter much in the long run though. Now the code is written: Twisted Names now runs the DNS for many domain names on the internet, the vt102 parser helped me get a job, and the company that drove the IMAP4 development is out of business. What really matters is what useful things you can do with the code now. As MattH points out, the resulting plethora of functionality has resulted in a library that (perhaps uniquely) addresses a wide array of interesting problems.

Why do we need such an event-driven library to write powerful servers when there are already very efficient implementations of various servers out there?
So paraphrasing: you can't imagine why anyone would need a toolkit when dyecast products already exist?
I'm guessing you've never needed to knock up a protocol gateway, e.g.
- write a daemon to md5 local files on demand over a unix socket
- interrogate a piece of software using udp and expose statistics over http.
I wrote a little proof-of-concept for the second example for a question here on SO in a handful of minutes. I couldn't do that without twisted.
Have you looked at: ProjectsUsingTwisted?

More on 'why': (disclaimer: I'm not a developer of Twisted proper), it's necessary to consider Twisted's high age (relative to Python's). When Twisted was written there was no sufficiently powerful non-blocking network/event driven library written around the reactor pattern (almost everyone was using threads back then). Twisted's initial use case was a large multiplayer game, although the specifics of this game seems to be somewhat lost in time.
Since the origins, as #MattH's link suggest, a very large amount of various network servers written in Python is based on Twisted.

This PyCon talk by the creator of Twisted should give you answers.
It has changed my opinion of Twisted. Before I viewed it as a massive piece of software with interfaces and weird names, two things that many developers dislike but that are actually just superficial things, and now that I’ve seen the history behind and the amazing number of use cases I respect it a lot. Life is short, you need Twisted :)

C/Python Socket Performance?

my question simply relates to the difference in performance between a socket in C and in Python. Since my Python build is CPython, I assume it's similar, but I'm curious if someone actually has "real" benchmarks, or at least an opinion that's evidence based.
My logics is as such:
C socket much faster? then write a C
extension.
not/barely a difference?
keep writing in Python and figure out
how to obtain packet level control
(scapy? dpkt?)
I'm sure someone will want to know for either context or curiosity. I plan to build a sort of proxy for myself (not for internet browsing, anonymity, etc) and will bind the application I want to use with it to a specific port. Then, all packets on said port will be queued, address header modified, and then sent, etc, etc.
Thanks in advance.

In general, sockets in Python perform just fine. For example, the reference implementation of the BitTorrent tracker server is written in Python.
When doing networking operations, the speed of the network is usually the limiting factor. That is, any possible tiny difference in speed between C and Python's socket code is completely overshadowed by the fact that you're doing networking of some kind.
However, your description of what you want to do indicates that you want to inspect and modify individual IP packets. This is beyond the capabilities of Python's standard networking libraries, and is in any case a very OS-dependent operation. Rather than asking "which is faster?" you will need to first ask "is this possible?"

i would think C would be faster, but python would be a lot easier to manage and use.
the difference would be so small, you wouldn't need it unless you were trying to send masses amount of data (something stupid like 1 million gb/second lol)
joe

Is there any Python module similar to Distributed Ruby

I am new to Python. Just want to know is there any module in python similar to ruby's drb? Like a client can use object provided by the drb server?

This is generally called "object brokering" and a list of some Python packages in this area can be found by browsing the Object Brokering topic area of the Python Package Index here.
The oldest and most widely used of these is Pyro.

Pyro does what I think you're discribing (although I've not used drb).
From the website:
Pyro is short for PYthon Remote Objects. It is an advanced and powerful Distributed Object Technology system written entirely in Python, that is designed to be very easy to use. Never worry about writing network communication code again, when using Pyro you just write your Python objects like you would normally. With only a few lines of extra code, Pyro takes care of the network communication between your objects once you split them over different machines on the network. All the gory socket programming details are taken care of, you just call a method on a remote object as if it were a local object!

The standard multiprocessing module might do what you want.

I have no idea what drb is, but from the little information you have given,
it might be something like the Perspective Broker in Twisted
Introduction
Suppose you find yourself in control
of both ends of the wire: you have two
programs that need to talk to each
other, and you get to use any protocol
you want. If you can think of your
problem in terms of objects that need
to make method calls on each other,
then chances are good that you can use
twisted's Perspective Broker protocol
rather than trying to shoehorn your
needs into something like HTTP, or
implementing yet another RPC
mechanism.
The Perspective Broker system
(abbreviated PB, spawning numerous
sandwich-related puns) is based upon a
few central concepts:
serialization: taking fairly arbitrary
objects and types, turning them into a
chunk of bytes, sending them over a
wire, then reconstituting them on the
other end. By keeping careful track of
object ids, the serialized objects can
contain references to other objects
and the remote copy will still be
useful.
remote method calls: doing
something to a local object and
causing a method to get run on a
distant one. The local object is
called a RemoteReference, and you do
something by running its .callRemote
method.

Have you looked at execnet?
http://codespeak.net/execnet/

For parallel processing and distributed computing I use parallel python.