Getters and setters don't violate encapsulation, they provide it. If you're using accessor methods, you are by definition not accessing an object's variables directly. You are instead using an interface that the object provides to manipulate some properties, and you don't care whether those properties are stored in ivars, stored in a dictionary, calculated from other values, etc. The implementor of the class in question remains free to change the way the class works without breaking existing client code so long as he or she maintains the interface.
Some say that if your interface consists of little more than a set of accessors for your instance variables, your class isn't doing enough to justify its existence, or you're not doing enough to hide the way the class works from external code. All that may be true, depending on the class, but it doesn't change the fact that access to the internal state (the ivars) is restricted to the class' own methods and therefore encapsulated.
There's obviously some disagreement in the comments below about what the term encapsulation means. I offer the following definition from the paper Encapsulation and Inheritance in Object-Oriented Programming Languages (pdf):
A module is encapsulated if clients are restricted by the definition
of the programming language to access the module only via its defined
external interface. Encapsulation thus assures designers that
compatible changes can be made safely, which facilitates program
evolution and maintenance. These benefits are especially important for
large systems and long-lived data.
It's hard to argue that accessors don't qualify as "defined external interface" to a class. If you also take steps to prevent external direct access to a class' internal state (that is, make your ivars 'private'), then by the definition above you will have achieved encapsulation.
From a pragmatic viewpoint, though, things aren't exactly that simple. The very next paragraph in the paper goes on to say:
To maximize the advantages of encapsulation, one should minimize the
exposure of implementation details in external interfaces. A
programming language supports encapsulation to the degree that it
allows minimal external interfaces to be defined and enforced.
Like any technique, encapsulation can be used well or not so well, and I think this is at the heart of most differences in opinion about what does or doesn't "break" encapsulation. If hiding the internal representation of data behind an external interface is good, then revealing only what is necessary for the class to do its job is better. A class which has a one-to-one correspondence between property accessors and ivars can properly be said to encapsulate its state, but it may not be using that encapsulation to best effect. I'd agree that if your code contains many classes in this situation, it's a good bet that the system is not as well designed as it could be.
How can you judge whether you're using encapsulation effectively? Continuing from the paper:
This support can be characterized by the kinds of changes that can
safely be made to the implementation of a module. For example, one
characteristic of an object-oriented language is whether it permits a
designer to define a class such that its instance variables can be
renamed without affecting clients.
I like this test because it provides a simple guideline that corresponds directly to the reason we value encapsulation in the first place. It also makes clear the idea that the benefit gained from encapsulation is a continuous value, not a binary one. We shouldn't lose sight of the fact that the paper describes encapsulation as a language feature, but I think it's safe to apply the test to specific code to help us decide how well that code uses the encapsulation provided by the language.
Example 1: Applying the "What kind of changes can safely be made?" test to the example in the OP's question, it seems likely that the code probably doesn't make good use of encapsulation. It may be technically true that the
set_byte_buffer_length() methods encapsulate some internal state, but if the "byte buffer" is an implementation detail rather than an important external property of the UDP server, the buffer shouldn't be exposed at all. The very fact that it is exposed limits the ways in which the UDP server can be modified.
Example 2: It's often said that inheritance breaks encapsulation because subclasses typically (depending on the language) have direct access to the parent class' internal state. Despite this, programmers can take advantage of encapsulation by using accessors (sometimes private accessors) to access state from a parent class instead of using the ivar itself.
When in doubt, a programmer should ask him or herself: Will my code break if the parent class changes? and Will subclasses of this class break if I change X?