shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
에이전트 스피크는 논리 프로그래밍과 신념-욕망-의도 소프트웨어 모델 (BDI) 아키텍처를 기반으로 하는 에이전트 지향 프로그래밍 언어이다.
JADE와 같이 자바 및 객체 지향성 뒤에 숨겨지지 않고 에이전트 지향 개념을 문자 그대로 번역한 Agent Speak (Jason)는 에이전트를 위한 "자연어"를 제공한다.
GOAL.
GOAL은 인지 에이전트를 프로그래밍하기 위한 프로그래밍 언어이다. GOAL 에이전트는 자신의 신념과 목표로부터 행동 선택을 도출한다. 이 언어는 에이전트의 신념과 목표를 조작하고 의사결정을 구조화하는 것을 허용하고 용이하게 하는 프로그래밍 구성을 통해 인지 에이전트를 설계하고 구현하기 위한 기본적인 빌딩 블록을 제공한다. 이 언어는 상식 또는 실용적 추론을 기반으로 하는 직관적인 프로그래밍 프레임워크를 제공한다.
SARL 언어.
SARL은 다중 에이전트 시스템 코딩을 위한 기본적인 추상화를 제공한다. 이는 스크립트와 유사한 구문(스칼라 및 루비에서 영감을 얻음)을 사용한다.
PADE (Python Agent DEvelopment framework).
PADE는 파이썬 언어로 지능형 에이전트를 개발하기 위한 파이썬 패키지이다. 이 프레임워크는 FIPA 및 ACL 표준을 준수한다.
class AgenteHelloWorld(Agent):
def __init__(self, aid):
super(AgenteHelloWorld, self).__init__(aid=aid)
display_message(self.aid.localname, "Hello World!")
모듈식 또는 확장 가능한 AOP 지원을 구현하는 한 가지 방법은 그 자체로 소프트웨어 에이전트로 구현되는 미들웨어 함수에 표준 AOP API를 정의하는 것이다. 예를 들어, 디렉토리 서비스는 FIPA 디렉토리 퍼실리테이터 또는 DF 소프트웨어 에이전트로 구현될 수 있다. 에이전트를 시작, 중지, 일시 중단 및 재개하는 생명 주기 관리는 FIPA 에이전트 관리 서비스 또는 AMS 에이전트로 구현될 수 있다. AOP 접근 방식의 이점은 다양한 응용 프로그램, 서비스 및 네트워크의 사용자 및 제공자 간에 더 동적인 역할을 지원한다는 것이다. 예를 들어, 전통적으로 네트워크 및 서비스는 일반적으로 고객을 대신하여 네트워크 및 서비스 제공자에 의해 관리되었고 단일 가상 네트워크 서비스로 제공되었지만, 고객 자신도 자신의 서비스를 통합하고 관리하는 데 더 많은 권한을 얻고 있다. 이는 AOP 및 유연하고 동적으로 통신을 관리할 수 있는 미들웨어 에이전트에 대한 API를 통해 달성될 수 있다.
속성 지향 프로그래밍 (Attribute-oriented programming, @OP)은 프로그램 코드 내에 속성이라는 메타데이터를 포함하는 기술이다.
다양한 언어에서의 속성 지향 프로그래밍.
Metadata Facility for Java(JSR-175)가 J2SE 5.0 릴리스에 포함되면서 속성 지향 프로그래밍을 바로 사용할 수 있게 되었다.
XDoclet 라이브러리를 사용하면 이전 버전의 자바에서도 속성 지향 프로그래밍 접근 방식을 사용할 수 있다.
C# 언어는 첫 릴리스부터 속성을 지원했다. 이러한 속성은 런타임 정보를 제공하는 데 사용되었으며 전처리기에서는 사용되지 않았다. 현재 소스 생성기를 사용하면 컴파일 시 추가 코드 생성을 주도하는 데 속성을 사용할 수 있다.
통합 모델링 언어 (UML)는 스테레오타입이라는 속성을 지원한다.
핵 프로그래밍 언어는 속성을 지원한다. 속성은 다양한 프로그램 엔티티에 첨부될 수 있으며, 해당 속성에 대한 정보는 리플렉션을 통해 런타임에 검색할 수 있다.
컴퓨터 과학에서 배열 프로그래밍(Array programming, 어레이 프로그래밍)은 전체 값 집합에 대해 한 번에 연산을 적용할 수 있는 솔루션을 의미한다. 이러한 솔루션은 일반적으로 계산과학 및 엔지니어링 환경에서 사용된다.
배열 프로그래밍을 지원하는 최신 프로그래밍 언어(또는 벡터 또는 다차원 언어라고도 함)는 스칼라에 대한 연산을 벡터, 행렬, 그리고 고차원 배열에 투명하게 적용하도록 특별히 설계되었다. 여기에는 APL, J, 포트란, 매트랩, Analytica, GNU 옥타브, R, 실크 플러스, 줄리아, 펄 데이터 언어(PDL), 라쿠가 포함된다. 이 언어들에서 전체 배열에 대해 작동하는 연산을 벡터화된 연산이라고 부를 수 있으며, 벡터 프로세서에서 실행되는지 여부와는 관계없이 벡터 명령을 구현한다. 배열 프로그래밍 프리미티브는 데이터 조작에 대한 광범위한 아이디어를 간결하게 표현한다. 간결성의 수준은 특정 경우에 극적일 수 있다. 객체 지향 코드 몇 페이지를 요구하는 배열 프로그래밍 언어 원 라이너를 흔히 볼 수 있다.
배열의 개념.
배열 프로그래밍의 기본 아이디어는 연산이 한 번에 전체 값 집합에 적용된다는 것이다. 이는 프로그래머가 개별 스칼라 연산의 명시적 루프에 의존할 필요 없이 전체 데이터 집합을 생각하고 조작할 수 있도록 해주기 때문에 고급 프로그래밍 모델이 된다.
케네스 아이버슨은 배열 프로그래밍(실제로는 APL을 지칭)의 근거를 다음과 같이 설명했다.
배열 프로그래밍 및 사고의 기본은 개별 요소가 유사하거나 인접한 데이터의 속성을 찾아 활용하는 것이다. 데이터를 구성 요소(또는 스칼라 양)로 암묵적으로 분해하는 객체 지향과 달리, 배열 지향은 데이터를 그룹화하고 균일하게 처리하려고 한다.
함수 랭크는 일반적으로 배열 프로그래밍 언어에 중요한 개념이며, 수학의 텐서 랭크에 비유할 수 있다. 데이터에 대해 작동하는 함수는 작동하는 차원의 수에 따라 분류될 수 있다. 예를 들어, 일반적인 곱셈은 0차원 데이터(개별 숫자)에 대해 작동하므로 스칼라 랭크 함수이다. 벡터곱 연산은 스칼라가 아닌 벡터에 대해 작동하므로 벡터 랭크 함수의 예이다. 행렬 곱셈은 2차원 객체(행렬)에 대해 작동하므로 2랭크 함수의 예이다. 축소 연산자는 입력 데이터 배열의 차원을 하나 이상 줄인다. 예를 들어, 요소에 대한 합계는 입력 배열을 1차원 줄인다.
배열 프로그래밍은 암묵적 병렬화에 매우 적합하다. 이는 오늘날 많은 연구가 진행되는 주제이다. 또한, 1997년 이후 개발 및 생산된 인텔 및 호환 CPU는 MMX부터 시작하여 SSSE3 및 3D나우!까지 다양한 명령어 집합 확장을 포함했으며, 이는 기본적인 단일 명령 다중 데이터 배열 기능을 포함한다. 이는 2020년대까지 AVX-512와 같은 명령어 집합으로 이어져 현대 CPU를 정교한 벡터 프로세서로 만들고 있다. 배열 처리는 병렬 처리와 구별된다. 배열 처리에서는 하나의 물리적 프로세서가 항목 그룹에 대해 동시에 연산을 수행하는 반면, 병렬 처리는 더 큰 문제를 더 작은 문제(다중 명령 다중 데이터)로 분할하여 여러 프로세서가 조각별로 해결하는 것을 목표로 한다. 2023년 현재 다중 코어 프로세서와 수천 개의 범용 컴퓨팅 코어를 갖춘 GPU가 일반적이다.
배열 프로그래밍 언어의 전형적인 예는 포트란, APL, J이다. 다른 언어로는 A+, Analytica, 채플, 대화형 데이터 언어, 줄리아, K, Klong, Q, 매트랩, GNU 옥타브, 싸이랩, FreeMat, 펄 데이터 언어(PDL), R, 라쿠, S-Lang, SAC, Nial, ZPL, Futhark, 그리고 TI-BASIC이 있다.
스칼라 언어.
C 및 파스칼과 같은 스칼라 언어에서는 연산이 단일 값에만 적용되므로 a+b는 두 숫자의 덧셈을 표현한다. 이러한 언어에서 한 배열을 다른 배열에 더하려면 인덱싱과 루프가 필요하며, 이는 코딩하기 번거롭다.
for (j = 0; j &lt; n; j++)
a[i][j] += b[i][j];
배열 기반 언어, 예를 들어 포트란에서는 위의 중첩된 for-루프를 한 줄로 배열 형식으로 작성할 수 있다.
또는 객체의 배열 속성을 강조하기 위해 다음과 같이 작성할 수도 있다.
C와 같은 스칼라 언어는 언어 자체의 기본 배열 프로그래밍 요소를 가지고 있지 않지만, 그렇다고 해서 이 언어로 작성된 프로그램이 벡터화의 기본 기술(즉, CPU에 벡터 기반 명령어가 있다면 이를 활용하거나 여러 CPU 코어를 사용하는 것)을 활용하지 않는다는 의미는 아니다. GCC와 같은 일부 C 컴파일러는 특정 최적화 수준에서 휴리스틱에 따라 이점을 얻을 수 있는 코드 섹션을 감지하고 벡터화한다. 또 다른 접근 방식은 OpenMP API에서 제공되며, 이를 통해 여러 CPU 코어를 활용하여 해당 코드 섹션을 병렬화할 수 있다.
배열 언어.
배열 언어에서는 연산이 스칼라와 배열 모두에 적용되도록 일반화된다. 따라서 a+b는 a와 b가 스칼라일 경우 두 스칼라의 합을 표현하고, 배열일 경우 두 배열의 합을 표현한다.
배열 언어는 프로그래밍을 단순화하지만, 추상화 패널티라는 비용이 발생할 수 있다. 덧셈이 코딩의 나머지 부분과 분리되어 수행되기 때문에 최적으로 효율적인 코드를 생성하지 못할 수 있다. (예를 들어, 동일한 배열의 다른 요소에 대한 덧셈이 동일한 실행 중에 나중에 발생하여 불필요한 반복 조회를 야기할 수 있다.) 가장 정교한 최적화 컴파일러조차도 프로그래머가 쉽게 수행할 수 있는 두 개 이상의 분명히 다른 함수를 통합하는 것은 매우 어려울 것이다. (프로그래머는 배열에 대한 동일한 패스에서 합계를 집계하여 계산 오버헤드를 최소화할 수 있다.)
이전 C 코드는 에이다 언어에서 다음과 같이 변경될 것이다. 이 언어는 배열 프로그래밍 구문을 지원한다.
APL.
APL은 구문적 설탕 없이 단일 문자 유니코드 심볼을 사용한다.
이 연산은 임의의 랭크(랭크 0 포함)의 배열, 그리고 스칼라와 배열에 대해 작동한다. Dyalog APL은 증가 할당으로 원래 언어를 확장한다.
Analytica.
Analytica는 에이다와 동일한 표현의 경제성을 제공한다.
다트머스 베이직은 세 번째 에디션(1966년)에 행렬 및 배열 조작을 위한 MAT 문을 가지고 있었다.
Mata.
Stata의 행렬 프로그래밍 언어 Mata는 배열 프로그래밍을 지원한다. 아래에서는 덧셈, 곱셈, 행렬과 스칼라의 덧셈, 요소별 곱셈, 첨자, 그리고 Mata의 많은 역행렬 함수 중 하나를 보여준다.
1 | 1 2 3 |
2 | 4 5 6 |
1 | 2 3 4 |
2 | 1 2 3 |
1 | 1 1 |
2 | 1 1 |
3 | 1 1 |
1 | 3 5 7 |
2 | 5 7 9 |
1 | 6 6 |
2 | 15 15 |
1 | 2 6 12 |
2 | 4 10 18 |
1 | 9 9 |
2 | 18 18 |
1 | 4 10 |
2 | 2 6 |
[symmetric]
1 | 0 |
2 | 0 3.25 |
3 | 0 -1.75 .9444444444 |
매트랩.
매트랩에서의 구현은 포트란 언어에서 허용되는 것과 동일한 경제성을 허용한다.
매트랩 언어의 변형인 GNU 옥타브 언어는 원래 언어를 증강 할당으로 확장한다.
매트랩과 GNU 옥타브 모두 행렬 곱셈, 역행렬, 연립 일차 방정식의 수치 해법과 같은 선형대수학 연산을 기본적으로 지원하며, 무어-펜로즈 유사역행렬도 사용한다.
두 배열의 내적에 대한 Nial 예제는 기본 행렬 곱셈 연산자를 사용하여 구현할 수 있다. codice_1가 [1 n] 크기의 행 벡터이고 codice_2가 [n 1] 크기의 해당 열 벡터인 경우.
대조적으로, 요소별 곱은 다음과 같이 구현된다.
a .* b;
동일한 수의 요소를 가진 두 행렬 간의 내적은 주어진 행렬을 열 벡터로 변형하는 보조 연산자 codice_3와 전치 행렬 연산자 codice_4를 사용하여 구현할 수 있다.
rasql.
rasdaman 쿼리 언어는 데이터베이스 지향적인 배열 프로그래밍 언어이다. 예를 들어, 두 배열은 다음 쿼리로 추가될 수 있다.
FROM A, B
R 언어는 기본적으로 배열 패러다임을 지원한다. 다음 예제는 두 행렬의 곱셈과 스칼라(실제로는 한 요소 벡터) 및 벡터의 덧셈 과정을 보여준다.
&gt; A &lt;- matrix(1:6, nrow=2) # !!this has nrow=2 ... and A has 2 rows
&gt; A
[,1] [,2] [,3]
[1,] 1 3 5
[2,] 2 4 6
&gt; B &lt;- t( matrix(6:1, nrow=2) ) # t() is a transpose operator !!this has nrow=2 ... and B has 3 rows --- a clear contradiction to the definition of A
&gt; B
[,1] [,2]
[1,] 6 5
[2,] 4 3
[3,] 2 1
&gt; C &lt;- A %*% B
&gt; C
[1,] 28 19
[2,] 40 28
&gt; D &lt;- C + 1
&gt; D
[1,] 29 20
[2,] 41 29
&gt; D + c(1, 1) # c() creates a vector
[1,] 30 21
[2,] 42 30
라쿠.
라쿠는 메타 연산자를 통해 배열 패러다임을 지원한다. 다음 예제는 더하기 연산자와 함께 하이퍼 연산자를 사용하여 배열 @a와 @b를 더하는 것을 보여준다.
[0] &gt; my @a = 1,1],[2,2],[3,3;
1 1] [2 2] [3 3
[1] &gt; my @b = 4,4],[5,5],[6,6;
4 4] [5 5] [6 6
[2] &gt; @a »+« @b;
5 5] [7 7] [9 9
수학적 추론과 언어 표기법.
행렬 왼쪽 나눗셈 연산자는 행렬의 일부 의미론적 속성을 간결하게 표현한다. 스칼라 등가물과 마찬가지로, 계수 (행렬) codice_5의 (행렬식이) 널이 아니면 양변에 codice_5의 역행렬 codice_7 (매트랩 및 GNU 옥타브 언어에서 codice_8)를 왼쪽에서 곱하여 (벡터) 방정식 codice_9를 풀 수 있다. 다음 수학적 진술은 codice_5가 풀 랭크 정사각 행렬일 때 유효하다.
여기서 codice_14는 동등 관계연산자이다.
이전 진술은 세 번째가 다른 것들보다 먼저 실행되면 유효한 매트랩 표현식이기도 하다 (반올림 오류로 인해 수치 비교가 거짓일 수 있음).
만약 시스템이 과결정되어 codice_5가 열보다 행이 많다면, 유사역행렬 codice_16 (매트랩 및 GNU 옥타브 언어에서는 codice_17)가 역행렬 codice_7를 대체할 수 있다.
그러나 이러한 해결책은 가장 간결하지도 않고 (예를 들어, 과결정된 시스템을 표기상으로 구별해야 하는 필요성이 여전히 남아 있음) 계산적으로도 가장 효율적이지 않다. 후자의 점은 스칼라 등가물 codice_19를 다시 고려할 때 쉽게 이해할 수 있다. 이 경우 해결책 codice_20는 더 효율적인 codice_21 대신 두 가지 연산이 필요할 것이다.
문제는 일반적으로 행렬 곱셈이 교환적이지 않다는 점이다. 이는 스칼라 해결책을 행렬 사례로 확장할 때 필요할 것이다.
매트랩 언어는 스칼라 사례와의 유사성의 본질적인 부분을 유지하기 위해 왼쪽 나눗셈 연산자 codice_26를 도입하여 수학적 추론을 단순화하고 간결성을 보존한다.
이는 코딩 관점에서 간결한 배열 프로그래밍의 예일 뿐만 아니라 계산 효율성 측면에서도 그러하다. 여러 배열 프로그래밍 언어에서는 ATLAS 또는 LAPACK과 같은 매우 효율적인 선형 대수 라이브러리의 이점을 누린다.
아이버슨의 이전 인용으로 돌아가면, 그 뒤에 숨겨진 근거는 이제 명백해질 것이다.
더 간결한 추상화를 제공하기 위해 특수하고 효율적인 라이브러리를 사용하는 것은 다른 프로그래밍 언어에서도 흔히 볼 수 있다. C++에서는 여러 선형대수 라이브러리가 언어의 연산자 오버로딩 기능을 활용한다. 어떤 경우에는 파이썬의 NumPy 확장 라이브러리, 아르마딜로 및 Blitz++ 라이브러리가 그러하듯이, 이러한 언어에서 매우 간결한 추상화가 배열 프로그래밍 패러다임의 명시적인 영향을 받는다.
오토마타 기반 프로그래밍(Automata-based programming)은 프로그램 또는 프로그램의 일부가 유한 상태 기계(FSM) 또는 다른 (종종 더 복잡한) 형식 오토마톤의 모델로 생각되는 프로그래밍 패러다임이다. 때로는 잠재적으로 무한한 상태 집합이 도입되기도 하는데, 이러한 집합은 단순히 열거에 그치지 않고 복잡한 구조를 가질 수 있다.
유한 상태 기계 기반 프로그래밍은 일반적으로 동일하지만, 형식적으로는 모든 가능한 변형을 다루지는 않는다. FSM이 유한 상태 기계를 의미하며, 오토마타 기반 프로그래밍이 엄격한 의미에서 FSM을 반드시 사용하는 것은 아니기 때문이다.
다음 속성들은 오토마타 기반 프로그래밍의 핵심 지표이다.
오토마타 기반 코드의 전체 실행은 오토마톤 단계의 주기이다.
오토마타 기반 프로그래밍의 개념을 사용하는 또 다른 이유는 이 기법에서 프로그램에 대해 생각하는 프로그래머의 사고방식이 튜링 기계, 마르코프 알고리즘 등을 사용하여 수학적 작업을 해결하는 데 사용되는 사고방식과 매우 유사하기 때문이다.
표준 입력에서 텍스트를 한 줄씩 읽어 각 줄의 첫 단어를 표준 출력에 쓰는 작업을 고려해 보자. 먼저 선행하는 공백 문자가 있으면 모두 건너뛴다. 그런 다음 첫 단어의 모든 문자를 출력한다. 마지막으로 새줄 문자가 나타날 때까지 후행 문자를 모두 건너뛴다. 스트림의 시작이 아닌 곳에서 새줄 문자 시퀀스가 나타나면 첫 번째만 출력하고 나머지는 건너뛴다. 그렇지 않으면 모두 건너뛴다. 다음으로 다음 줄에서 프로세스를 다시 시작한다. 파일 끝 조건이 발생하면(단계에 관계없이) 중지한다.
전통적인 프로그램.
위 작업을 수행하는 C 언어의 전통적인 프로그램은 다음과 같을 수 있다.
c = getchar();
} while (isspace(c));
while (!isspace(c) &amp;&amp; c != EOF) {
while (c != '\n' &amp;&amp; c != EOF) {
if (c == '\n') {
} while (c != EOF);
예를 들어, 위 프로그램을 다음 입력으로 컴파일하고 실행하면:
$ clang program.c &amp;&amp; (printf "\t\v\f\r \n\n\t\v\f\r foo bar baz\n\n\t\v\f\r qux quux corge" | ./a.out)
다음과 같은 결과가 나온다.
오토마타 기반 프로그램.
절차적.
동일한 작업은 유한 상태 기계 관점에서 생각하여 해결할 수 있다. 한 줄의 파싱은 세 단계로 나뉜다. 선행 공백 문자를 건너뛰는 단계, 첫 번째 단어의 문자를 출력하는 단계, 그리고 후행 문자를 건너뛰는 단계이다. 이 상태들을 codice_1, codice_2, codice_3라고 부른다. 오토마타 기반 프로그램 버전은 다음과 같을 수 있다.
enum State {BEFORE, INSIDE, AFTER};
enum State s = BEFORE;
while ((c = getchar()) != EOF) {
switch (s) {
case BEFORE:
if (!isspace(c)) {
s = INSIDE;
case INSIDE:
s = BEFORE;
} else if (isspace(c)) {
s = AFTER;
case AFTER:
프로그램이 더 길어졌지만, 적어도 한 가지 중요한 장점이 있다. 읽기(즉, codice_4 함수 호출) 명령이 하나뿐이다. 게다가 전통적인 버전이 네 개였던 루프 대신 루프가 하나뿐이다. codice_5 루프의 본문은 오토마톤 단계이고, 루프 자체는 오토마톤 단계의 주기이다. 이 프로그램은 상태도에 표시된 유한 상태 기계의 작동을 구현한다.
이 프로그램의 가장 중요한 속성은 오토마톤 단계 코드 섹션이 명확하게 지역화되어 있다는 것이다. 오토마톤 단계를 위한 명시적인 codice_6 함수를 사용하면 이 속성을 더 잘 보여준다.
void step(enum State* const s, int const c) {
switch (*s) {
*s = INSIDE;
*s = BEFORE;
*s = AFTER;
step(&amp;s, c);
이제 프로그램은 오토마타 기반 코드의 기본 속성을 명확하게 보여준다.
유한 오토마톤은 상태 전이표로 정의될 수 있으며, 행은 현재 상태를 나타내고, 열은 입력을 나타내며, 셀은 다음 상태와 수행할 동작을 나타낸다.
일반적으로 오토마타 기반 프로그램은 이 접근 방식을 자연스럽게 사용할 수 있다. 상태 전이표를 위한 명시적인 2차원 배열 codice_7를 사용하면 프로그램은 이 접근 방식을 사용한다.
void print(int const c) {
struct Branch {
enum State const next_state;
void (*action)(int);
struct Branch const transitions[3][3] = {
// newline whitespace other Inputs/States
, // before
, // inside
// after
int const row = (*s == BEFORE) ? 0 : (*s == INSIDE) ? 1 : 2;
int const column = (c == '\n') ? 0 : isspace(c) ? 1 : 2;
struct Branch const* const b = &amp;transitions[row][column];
*s = b-&gt;next_state;
b-&gt;action(c);
구현 언어가 객체 지향 프로그래밍을 지원한다면, 프로그램의 간단한 리팩토링은 오토마톤을 객체로 캡슐화하여 구현 세부 사항을 숨기는 것이다. 객체 지향 스타일을 사용하는 C++ 프로그램은 다음과 같을 수 있다.
StateMachine();
void feedChar(int);
static void nop(int);
static void print(int);
enum State _state;
static struct Branch const _transitions[3][3];
void StateMachine::feedChar(int const c) {
int const row = (_state == BEFORE) ? 0 : (_state == INSIDE) ? 1 : 2;
struct Branch const* const b = &amp;_transitions[row][column];
_state = b-&gt;next_state;
void StateMachine::print(int const c) {
struct Branch const StateMachine::_transitions[3][3] = {
StateMachine m;
m.feedChar(c);
문서의 주제와 직접적으로 관련 없는 변경 사항을 최소화하기 위해 C 표준 라이브러리의 입출력 codice_4 및 codice_9 함수가 사용되고 있다.
상태 디자인 패턴은 객체가 대규모 조건문이나 테이블 검색에 의존하지 않고 가상 함수 호출 덕분에 내부 상태에 따라 런타임에 동작을 변경하는 방법이다. 대규모 조건문을 사용하는 코드에 비해 주요 장점은 상태별 코드가 단일 블록에 집중되지 않고 여러 객체에 분산되어 유지보수성이 향상된다는 것이다. 상태 전이표를 사용하는 코드에 비해 주요 장점은 가상 함수 호출이 테이블 검색보다 효율적인 경우가 많고, 상태 전이 기준이 표 형식보다 더 명시적이며, 상태 전이에 수반되는 동작을 추가하기가 더 쉽다는 것이다. 그러나 새로운 문제가 발생한다. 클래스 수가 코드의 압축성을 다른 접근 방식보다 떨어뜨린다. 상태 디자인 패턴을 사용하는 프로그램은 다음과 같을 수 있다.
class StateMachine;
class State {
virtual void feedChar(StateMachine*, int) const = 0;
class Before: public State {
static State const* instantiate();
virtual void feedChar(StateMachine*, int) const override;
Before() = default;
static State const* _instance;
class Inside: public State {
Inside() = default;
class After: public State {
After() = default;
void setState(State const*);
State const* _state;
friend class Before;
friend class Inside;
friend class After;
State const* Before::instantiate() {
if (!_instance) {
_instance = new Before;
void Before::feedChar(StateMachine* const m, int const c) const {
m-&gt;setState(Inside::instantiate());
State const* Before::_instance = nullptr;
State const* Inside::instantiate() {
_instance = new Inside;
void Inside::feedChar(StateMachine* const m, int const c) const {
m-&gt;setState(Before::instantiate());
m-&gt;setState(After::instantiate());
State const* Inside::_instance = nullptr;
State const* After::instantiate() {
_instance = new After;
void After::feedChar(StateMachine* const m, int const c) const {
State const* After::_instance = nullptr;
_state-&gt;feedChar(this, c);
void StateMachine::setState(State const* const s) {
_state = s;
자동화와 오토마타.
오토마타 기반 프로그래밍은 실제로 자동화 분야에서 발견되는 프로그래밍 요구 사항과 밀접하게 일치한다.
생산 주기는 일반적으로 다음과 같이 모델링된다.
다양한 전용 프로그래밍 언어는 이러한 모델을 다소 정교한 방식으로 표현할 수 있도록 한다.
자동화 프로그램.
위에 제시된 예시는 다음 의사코드와 같이 이 관점에 따라 표현될 수 있다 ('set'은 논리 변수를 활성화하고, 'reset'은 논리 변수를 비활성화하며, ':'는 변수를 할당하고, '='는 동등성을 테스트한다).
newline: '\n'
whitespace: ('\t', '\n', '\v', '\f', '\r', ' ')
states: (before, inside, after)
if before and (c != newline and c not in whitespace) then set inside
if inside then (if c in whitespace then set after else if c = newline then set before)
if after and c = newline then set before
if before and (c != newline and c not in whitespace) then write(c)
if inside and c not in whitespace then write(c)
if after and c = newline then write(c)
loop until (c: readCharacter) = EOL {
사이클 진행을 표현하는 루틴과 실제 동작(입력 및 출력 일치)을 표현하는 루틴을 분리하면 더 명확하고 간단한 코드를 얻을 수 있다.
자동화 분야에서는 단계별 진행이 기계 자체에서 오는 입력 데이터에 따라 달라진다. 이는 프로그램에서 텍스트에서 문자를 읽는 것으로 표현된다. 실제로는 이러한 데이터가 기계의 주요 요소의 위치, 속도, 온도 등을 알려준다.
GUI 프로그래밍에서와 마찬가지로, 기계 상태의 변경은 최종 상태에 도달할 때까지 한 상태에서 다른 상태로의 전환을 유발하는 이벤트로 간주될 수 있다. 가능한 상태의 조합은 다양한 이벤트를 생성하여 더 복잡한 생산 주기를 정의한다. 결과적으로 주기는 일반적으로 단순한 선형 시퀀스와는 거리가 멀다. 일반적으로 동시에 실행되는 병렬 분기와 다양한 이벤트에 따라 선택되는 대안이 있으며, 이는 아래에 개략적으로 표시되어 있다.
s:단계 c:조건
|-c2
|-c31 |-c32
s31 s32
|-c41 |-c42
오토마타 기반 프로그래밍은 어휘 및 구문 분석에서 널리 사용된다.
그 외에도 오토마타 관점에서 생각하는 것(즉, 실행 프로세스를 오토마톤 단계로 분해하고 명시적인 오토마톤 상태를 통해 단계별로 정보를 전달하는 것)은 병렬 프로세스나 스레드를 사용하는 유일한 대안으로서 사건 기반 프로그래밍에 필요하다.
상태 및 상태 기계의 개념은 형식 명세 분야에서 자주 사용된다. 예를 들어, UML 기반 소프트웨어 아키텍처 개발은 프로그램의 동작을 지정하기 위해 상태도를 사용한다. 또한 다양한 통신 프로토콜도 종종 명시적인 상태 개념을 사용하여 지정된다(예: ).
오토마타 관점(단계 및 상태)에서 생각하는 것은 일부 프로그래밍 언어의 의미를 설명하는 데에도 사용될 수 있다. 예를 들어, 레팔 언어로 작성된 프로그램의 실행은 소위 추상 레팔 기계의 단계 시퀀스로 설명된다. 기계의 상태는 뷰(변수 없는 임의의 레팔 표현식)이다.
스킴 언어의 연속은 스킴 자체가 오토마타와 전혀 관련이 없지만(재귀적이다) 단계와 상태의 관점에서 생각하는 것을 요구한다. call/cc 기능이 작동하도록 하려면 구현이 실행 중인 프로그램의 전체 상태를 포착할 수 있어야 하며, 이는 상태에 암시적인 부분이 없을 때만 가능하다. 이러한 포착된 상태가 바로 연속이라고 불리는 것이며, 이는 (상대적으로 복잡한) 오토마톤의 상태로 간주될 수 있다. 오토마톤 단계는 이전 연속에서 다음 연속을 추론하는 것이고, 실행 프로세스는 이러한 단계의 주기이다.
알렉산더 올롱그렌(Alexander Ollongren)은 그의 저서에서 형식 오토마타에 전적으로 기반을 둔 프로그래밍 언어 의미론 기술의 소위 비엔나 방법을 설명한다.
STAT 시스템 은 오토마타 기반 접근 방식을 사용하는 좋은 예시이다. 이 시스템은 다른 기능 외에도 순전히 오토마타 지향적인 STATL이라는 임베디드 언어를 포함한다.
오토마타 기반 기술은 형식 언어 분석과 같은 오토마타 이론에 기반을 둔 알고리즘이 있는 영역에서 널리 사용되었다.
이 분야의 초기 논문 중 하나는 존슨(Johnson) 외 공저, 1968년이다.
오토마타 기반 프로그래밍이 일반적인 기술로 언급된 가장 초기의 사례 중 하나는 페테르 나우르의 1963년 논문에서 찾아볼 수 있다. 저자는 이 기술을 튜링 기계 접근법이라고 부르지만, 논문에는 실제 튜링 기계가 주어지지 않았다. 대신 단계와 상태에 기반한 기술이 설명되어 있다.
명령형 및 절차적 프로그래밍과의 비교.
상태의 개념은 오토마타 기반 프로그래밍만의 고유한 속성이 아니다.
일반적으로 말해, 컴퓨터 프로그램의 실행 중에 변경될 수 있는 모든 정보의 조합으로서 상태(또는 프로그램 상태)가 나타난다. 예를 들어, 전통적인 명령형 프로그래밍 프로그램의 상태는 다음으로 구성된다.
이들은 명시적 부분(변수에 저장된 값 등)과 암시적 부분(반환 주소 및 명령어 포인터)으로 나눌 수 있다.
이러한 점을 고려할 때, 오토마타 기반 프로그램은 상태의 암시적 부분이 최소화된 명령형 프로그램의 특별한 경우로 간주될 수 있다. 단계 코드 섹션에 진입하는 두 개의 다른 순간에 취한 전체 프로그램의 상태는 오토마톤 상태에서만 다를 수 있다. 이는 프로그램 분석을 단순화한다.
객체 지향 프로그래밍 관계.
객체 지향 프로그래밍 이론에서 객체는 내부 상태를 가지며 메시지를 수신하고, 응답하며, 다른 객체에 메시지를 보내고, 메시지 처리 중 내부 상태를 변경할 수 있다고 한다. 보다 실용적인 용어로, 객체의 메서드를 호출하는 것은 객체에 메시지를 보내는 것과 동일하게 간주된다.
따라서 한편으로 객체 지향 프로그래밍의 객체는 상태가 private 필드의 조합이고 하나 이상의 메서드가 단계로 간주되는 오토마타(또는 오토마타 모델)로 간주될 수 있다. 이러한 메서드는 직접 또는 간접적으로 서로 또는 자신을 호출해서는 안 된다. 그렇지 않으면 객체가 오토마타 기반 방식으로 구현된 것으로 간주될 수 없다.
다른 한편으로, 객체는 오토마톤 모델을 구현하는 데 적합하다. 오토마타 기반 접근 방식이 객체 지향 언어 내에서 사용될 때, 오토마톤 모델은 일반적으로 클래스로 구현되고, 상태는 클래스의 private 필드로 표현되며, 단계는 메서드로 구현된다. 이러한 메서드는 일반적으로 클래스의 유일한 비상수 공개 메서드이다(생성자 및 소멸자 제외). 다른 공개 메서드는 상태를 쿼리할 수 있지만 변경하지는 않는다. 모든 보조 메서드(특정 상태 핸들러 등)는 일반적으로 클래스의 private 부분 내에 숨겨진다.
MAC 스푸핑(MAC spoofing)은 네트워크 인터페이스의 MAC 주소를 공장에서 할당된 것에서 변경하는 기술이다. 네트워크 인터페이스 컨트롤러(NIC)에 하드 코딩된 MAC 주소는 변경할 수 없다. 그러나 많은 장치 드라이버는 MAC 주소를 변경할 수 있도록 허용한다. 또한 운영 체제가 NIC가 사용자가 선택한 MAC 주소를 가지고 있다고 믿게 만들 수 있는 도구들이 있다. MAC 주소를 숨기는 과정을 MAC 스푸핑이라고 한다. 본질적으로 MAC 스푸핑은 어떤 이유로든 컴퓨터의 신원을 변경하는 것을 의미한다.
할당된 MAC 주소를 변경하면 사용자가 서버나 라우터의 접근 제어 목록을 우회할 수 있으며, 네트워크에서 컴퓨터를 숨기거나 다른 네트워크 장치를 사칭할 수 있다. 또한 MAC 주소 블랙리스트를 우회하여 Wi-Fi 네트워크에 다시 액세스할 수 있다. 그러나 자동 MAC 필터링이 켜져 있는 경우 MAC 스푸핑은 자녀 보호 기능을 우회하는 데 작동하지 않는다. MAC 스푸핑은 합법적인 목적과 불법적인 목적 모두에 사용된다.
기존 ISP를 위한 새 하드웨어.
많은 ISP는 서비스 및 요금 청구를 위해 고객의 MAC 주소를 등록한다. MAC 주소는 네트워크 인터페이스 컨트롤러(NIC) 카드에 고유하게 하드 코딩되어 있기 때문에, 고객이 새 장치를 연결하거나 기존 장치를 변경하려고 할 때 ISP는 다른 MAC 주소를 감지하고 해당 새 장치에 인터넷 액세스를 허용하지 않을 수 있다. 이는 MAC 스푸핑을 통해 쉽게 우회할 수 있으며, 고객은 새 장치의 MAC 주소를 ISP에 등록된 MAC 주소처럼 보이도록 스푸핑하기만 하면 된다. 이 경우 고객은 여러 장치에서 인터넷 액세스를 얻기 위해 MAC 주소를 스푸핑한다. 이는 일반적으로 합법적인 경우이지만, ISP의 사용자 계약이 사용자가 서비스에 두 대 이상의 장치를 연결하는 것을 금지하는 경우 새 장치의 MAC 스푸핑은 불법으로 간주될 수 있다. 더욱이, ISP에 액세스하기 위해 MAC 주소를 스푸핑할 수 있는 사람은 고객만이 아니다. 컴퓨터 크래커는 동일한 기술을 통해 ISP에 무단으로 액세스할 수 있다. 이를 통해 승인되지 않은 서비스에 액세스하면서 고객의 신원을 사용하여 식별 및 추적이 어려워진다. 이러한 행위는 MAC 스푸핑의 불법적이고 부당한 사용으로 간주된다.
이는 케이블 모뎀 및 DSL 모뎀과 같은 고객 댁내 장치에도 적용된다. 고객에게 월별로 임대되는 장비는 공급자의 분배 네트워크에 알려진 하드 코딩된 MAC 주소를 가지고 있어, 고객이 연체되지 않는 한 서비스가 제공될 수 있다. 공급자가 고객에게 자체 장비를 제공하도록 허용하는 경우(따라서 월별 임대료를 피할 수 있음), 공급자는 때때로 서비스가 제공되기 전에 고객이 장비의 MAC 주소를 제공하도록 요구한다.
소프트웨어 요구사항 충족.
일부 소프트웨어는 소프트웨어 사용권 동의에 명시된 미리 정의된 MAC 주소를 가진 시스템에만 설치 및 실행될 수 있으며, 사용자는 소프트웨어에 액세스하기 위해 이 요구 사항을 준수해야 한다. 원래 장치 오작동으로 인해 사용자가 다른 하드웨어를 설치해야 하거나 사용자 NIC 카드에 문제가 있는 경우 소프트웨어는 새 하드웨어를 인식하지 못한다. 그러나 이 문제는 MAC 스푸핑을 사용하여 해결할 수 있다. 사용자는 새 MAC 주소를 스푸핑하여 소프트웨어가 등록되었을 때 사용 중이던 주소처럼 보이도록 해야 한다. MAC 스푸핑을 사용하여 소프트웨어를 여러 장치에서 동시에 실행하면 법적 문제가 발생할 수 있다. 동시에 사용자는 라이선스를 확보하지 못한 소프트웨어에 액세스할 수 있다. 소프트웨어에 액세스하지 못하게 하는 하드웨어 문제가 있는 경우 소프트웨어 공급업체에 문의하는 것이 가장 안전한 방법일 수 있다.
일부 소프트웨어는 또한 승인되지 않은 사용자가 소프트웨어로 자유롭게 접근할 수 있는 특정 네트워크에 접근할 수 없도록 MAC 필터링을 수행할 수 있다. 이러한 경우는 불법적이거나 불법적인 활동으로 간주될 수 있으며 법적 조치가 취해질 수 있다.
신원 마스킹.
사용자가 개인 정보를 보호하기 위해 MAC 주소를 스푸핑하기로 선택하는 경우, 이를 신원 마스킹이라고 한다. 동기의 한 예로, Wi-Fi 네트워크 연결에서 MAC 주소는 암호화되지 않는다. 심지어 보안 IEEE 802.11i-2004 (WPA) 암호화 방법도 Wi-Fi 네트워크가 MAC 주소를 전송하는 것을 막지 못한다. 따라서 추적을 피하기 위해 사용자는 장치의 MAC 주소를 스푸핑하기로 선택할 수 있다. 그러나 컴퓨터 크래커는 동일한 기술을 사용하여 MAC 필터링과 같은 액세스 제어 방법을 우회하고 신원을 드러내지 않는다. MAC 필터링은 연결하려는 장치의 MAC 주소가 허용된 주소와 일치하지 않으면 네트워크 액세스를 차단하며, 일부 네트워크에서 사용된다. 컴퓨터 크래커는 MAC 스푸핑을 사용하여 허용된 MAC 주소 중 하나라도 알고 있다면 MAC 필터링을 사용하는 네트워크에 액세스할 수 있으며, 손상을 입힐 의도를 가질 수 있지만 네트워크의 합법적인 사용자 중 한 명처럼 보일 수 있다. 결과적으로 실제 범죄자는 법 집행 기관에 의해 감지되지 않을 수 있다.
Wi-Fi의 MAC 주소 무작위화.
제3자가 MAC 주소를 사용하여 장치를 추적하는 것을 방지하기 위해 안드로이드, 리눅스, iOS, macOS 및 윈도우는 MAC 주소 무작위화를 구현했다. 2014년 6월, 애플은 iOS의 향후 버전에서 모든 Wi-Fi 연결에 대한 MAC 주소를 무작위화할 것이라고 발표했다. 리눅스 커널은 2015년 3월부터 네트워크 스캔 중 MAC 주소 무작위화를 지원했지만, 드라이버는 이 기능을 사용하도록 업데이트되어야 한다. 윈도우는 윈도우 10이 2015년 7월에 출시된 이후 이를 지원했다.
MAC 주소 스푸핑은 불법은 아니지만, 일부 경우에 논란을 일으켰다. 2012년 JSTOR 디지털 라이브러리에서 불법적으로 파일에 접근한 혐의로 기소된 인터넷 핵티비스트 에런 스워츠에 대한 기소에서 검찰은 그가 MAC 주소를 스푸핑했기 때문에 이는 범죄 행위를 저지를 의도적인 의도를 보여준다고 주장했다. 2014년 6월, 애플은 iOS 플랫폼의 향후 버전에서 모든 Wi-Fi 연결에 대한 MAC 주소를 무작위화하여 인터넷 서비스 제공업체가 사용자 활동 및 신원을 추적하기 더 어렵게 만들 것이라고 발표했으며, 이는 여러 블로그와 신문에서 MAC 스푸핑의 관행을 둘러싼 도덕적 및 법적 논쟁을 다시 불러일으켰다.
MAC 주소 스푸핑은 로컬 브로드캐스트 도메인으로 제한된다. 발신자가 자신의 IP 주소를 스푸핑하여 수신자가 응답을 다른 곳으로 보내도록 하는 IP 주소 스푸핑과 달리, MAC 주소 스푸핑에서는 MAC 필터링이 켜져 있지 않으면 스푸핑 당사자가 응답을 수신하여 스푸핑자가 새 장치를 사칭할 수 있다.
브로드캐스트 도메인(Broadcast domain)은 컴퓨터 망의 논리적 구분으로, 모든 노드가 데이터 링크 계층에서 브로드캐스트를 통해 서로 도달할 수 있는 영역이다. 브로드캐스트 도메인은 동일한 LAN 세그먼트 내에 있거나 다른 LAN 세그먼트에 브리징될 수 있다.
현재 널리 사용되는 기술적인 관점에서, 동일한 이더넷 리피터 또는 스위치에 연결된 모든 컴퓨터는 동일한 브로드캐스트 도메인의 구성원이다. 나아가, 상호 연결된 동일한 스위치 또는 리피터 세트에 연결된 모든 컴퓨터는 동일한 브로드캐스트 도메인의 구성원이다. 라우터 및 기타 네트워크 계층 장치는 브로드캐스트 도메인 간의 경계를 형성한다.
브로드캐스트 도메인의 개념은 충돌 도메인과 비교될 수 있는데, 충돌 도메인은 동일한 상호 연결된 리피터 세트의 모든 노드를 의미하며 스위치와 네트워크 브리지에 의해 분할된다. 충돌 도메인은 일반적으로 브로드캐스트 도메인보다 작으며 그 안에 포함된다. 일부 데이터 링크 계층 장치가 충돌 도메인을 분할할 수 있지만, 브로드캐스트 도메인은 라우터나 레이어 3 스위치와 같은 네트워크 계층 장치에 의해서만 분할된다. VLAN을 분리하는 것도 브로드캐스트 도메인을 분할한다.
브로드캐스트 도메인과 충돌 도메인의 구분은 단순 이더넷 및 유사 시스템이 통신을 위해 공유 매체를 사용하기 때문에 발생한다. 단순 이더넷(스위치나 브리지 없이)에서는 데이터 프레임이 네트워크의 다른 모든 노드로 전송된다. 각 수신 노드는 각 프레임의 목적지 주소를 확인하고 자신의 MAC 주소 또는 브로드캐스트 주소로 지정되지 않은 프레임은 무시한다.
스위치는 버퍼 역할을 하며, 각 연결된 네트워크 세그먼트에서 프레임을 수신하고 분석한다. 발신 세그먼트에 연결된 노드를 대상으로 하는 프레임은 스위치에 의해 포워딩되지 않는다. 다른 세그먼트의 특정 노드를 대상으로 하는 프레임은 해당 세그먼트로만 전송된다. 오직 브로드캐스트 프레임만 다른 모든 세그먼트로 포워딩된다. 이는 불필요한 트래픽과 충돌을 줄인다.
이러한 스위치드 네트워크에서는 전송된 프레임이 다른 모든 도달 가능한 노드에 의해 수신되지 않을 수 있다. 명목상, 브로드캐스트 프레임만이 다른 모든 노드에 의해 수신될 것이다. 충돌은 발생한 물리 계층 네트워크 세그먼트에 국한된다. 따라서 브로드캐스트 도메인은 전체 상호 연결된 레이어 2 네트워크이며, 각 스위치 또는 브리지 포트에 연결된 세그먼트는 각각 충돌 도메인이다. 명확히 말하자면, 리피터는 충돌 도메인을 분할하지 않지만 스위치는 분할한다. 이는 스위치가 보편화됨에 따라 충돌 도메인이 스위치 포트와 연결된 노드 간의 특정 세그먼트로 격리되었음을 의미한다. 전이중 세그먼트 또는 링크는 각 송신기와 수신기 사이에 전용 채널이 있어 충돌 가능성이 없으므로 충돌 도메인을 형성하지 않는다.
브로드캐스트 도메인 제어.
충분히 정교한 스위치를 사용하면 브로드캐스트 도메인이 엄격하게 제어되는 네트워크를 생성할 수 있다. 이 개념의 한 가지 구현은 사설 VLAN이다. 또 다른 구현은 리눅스와 iptables를 통해 가능하다. 한 가지 비유는 여러 VLAN을 생성함으로써 브로드캐스트 도메인의 수가 증가하지만 각 브로드캐스트 도메인의 크기는 감소한다는 것이다. 이는 VLAN이 브로드캐스트 도메인을 정의하기 때문이다.
이는 MAC 주소 또는 스위치 포트를 통해 하나 이상의 제공자 노드를 지정함으로써 달성된다. 브로드캐스트 프레임은 이러한 소스에서 시작될 수 있으며 다른 모든 노드로 전송된다. 다른 모든 소스에서 오는 브로드캐스트 프레임은 제공자 노드로만 전달된다. 제공자 노드로 향하지 않는 다른 소스에서 오는 트래픽(P2P 트래픽)은 차단된다.
그 결과는 명목상 공유 전송 시스템인 이더넷을 기반으로 하지만, 클라이언트 노드들이 서로 통신할 수 없고 제공자와만 통신하는 네트워크이다. 클라이언트 노드 간의 직접적인 데이터 링크 계층 통신을 허용하는 것은 ARP 스푸핑과 같은 다양한 보안 공격에 네트워크를 노출시킨다.
브로드캐스트 주소(Broadcast address, 브로드캐스트 어드레스)는 다중 접근 통신망에 연결된 모든 장치로 전송하는 데 사용되는 네트워크 주소이다. 브로드캐스트 주소로 전송된 메시지는 네트워크에 연결된 모든 호스트에 의해 수신될 수 있다.
이와 대조적으로, 멀티캐스트 주소는 특정 장치 그룹에 주소를 지정하는 데 사용되며, 유니캐스트 주소는 단일 장치에 주소를 지정하는 데 사용된다.
네트워크 계층 통신의 경우, 브로드캐스트 주소는 특정 IP 주소일 수 있다. 이더넷 네트워크의 데이터 링크 계층에서는 특정 MAC 주소이다.
IP 네트워킹.
인터넷 프로토콜 버전 4(IPv4) 네트워크에서 브로드캐스트 주소는 IP 주소의 호스트 식별 부분에 있는 특수 값이다. 모든 1의 값은 브로드캐스트를 지원하는 네트워크의 표준 브로드캐스트 주소로 설정되었다. 모든 1의 주소를 사용하는 이 방법은 1982년 R. 거위츠와 R. 힌덴에 의해 처음 제안되었다. 이후 부분망과 클래스 없는 도메인 간 라우팅이 도입되면서 약간 변경되어, 모든 1의 값은 로컬 브로드캐스트 주소가 되고 각 부분망의 모든 1의 호스트 주소는 해당 부분망의 지정 브로드캐스트 주소가 된다.
모든 IPv4 호스트의 지정 브로드캐스트 주소는 부분망 마스크의 비트 보수 (비트 단위 NOT)를 취한 다음 호스트 IP 주소와 비트 단위 OR 연산을 수행하여 얻을 수 있다. 이 과정의 단축키(0과 1 비트 배치만 사용하는 일반적인 마스크의 경우)는 단순히 호스트 IP 주소를 취하고 주소의 호스트 식별자 부분에 있는 모든 비트(부분망 마스크에 0을 포함하는 모든 비트 위치)를 1로 설정하는 것이다.
아래 예시에서 볼 수 있듯이, 부분망 마스크가 인 사설 IP 주소 공간 를 사용하는 전체 IPv4 부분망으로 패킷을 전송하기 위한 지정 브로드캐스트 주소를 계산하기 위해, 브로드캐스트 주소는 을 와 비트 단위 OR하여 로 계산된다. 지정 브로드캐스트는 항상 부분망 내에서 작동하지만, 보안상의 이유로 많은 라우터는 기본적으로 이러한 포워딩을 비활성화한다.
IP 주소 에 대한 특별한 정의가 존재한다. 이것은 제로 네트워크 또는 의 브로드캐스트 주소이며, 인터넷 프로토콜 표준에서 이 네트워크, 즉 로컬 네트워크를 의미한다. 이 주소로의 전송은 정의상 제한되어 있으며, 로컬 네트워크를 다른 네트워크에 연결하는 라우터에 의해 절대 전달되지 않는다.
IP 브로드캐스트는 BOOTP 및 DHCP 클라이언트가 각 서버를 찾고 요청을 보내는 데 사용된다.
인터넷 프로토콜 버전 6(IPv6)은 이러한 브로드캐스트 방식을 구현하지 않으므로 브로드캐스트 주소를 정의하지 않는다. 대신 IPv6는 모든 호스트 멀티캐스트 그룹에 멀티캐스트 주소를 사용한다. 그러나 모든 호스트 주소를 사용하도록 정의된 IPv6 프로토콜은 없으며, 대신 특정 링크-로컬 멀티캐스트 주소에서 송수신한다. 이로 인해 네트워크 호스트가 멀티캐스트 주소를 기반으로 트래픽을 필터링할 수 있고 모든 브로드캐스트 또는 모든 호스트 멀티캐스트를 처리할 필요가 없으므로 효율성이 높아진다.
브로드캐스트는 이더넷 네트워크의 하위 데이터 링크 계층에서도 가능하다. 프레임이 MAC 주소 로 지정되면 주어진 LAN 세그먼트의 모든 컴퓨터에 도달하도록 주소가 지정된다. IP 브로드캐스트 패키지를 포함하는 이더넷 프레임은 일반적으로 이 주소로 전송된다.
이더넷 브로드캐스트는 특히 주소 결정 프로토콜에 의해 IP 주소를 MAC 주소로 확인하는 데 사용된다.
IPX 네트워킹.
인터네트워크 패킷 교환 (IPX)은 브로드캐스트를 허용한다. 네트워크 번호가 FFFFFFFF인 패킷은 사용 가능한 모든 네트워크로 전송된다. 노드 번호가 FFFFFFFFFFFF로 지정되면 패킷은 네트워크의 모든 호스트가 수신하도록 의도된 것이다.
애플토크.
애플토크 프로토콜은 브로드캐스트를 허용한다. 노드 ID가 255로 지정되면 패킷은 사용 가능한 모든 네트워크로 전송된다.
충돌 도메인(Collision domain)은 두 개 이상의 장치가 동시에 네트워크 세그먼트에서 패킷을 보내려고 시도하여 데이터 전송이 서로 충돌하는 공유 매체 또는 중계기를 통해 연결된 네트워크 세그먼트이다. 충돌 도메인은 특히 무선망에 적용되지만 초기 버전의 이더넷에도 영향을 미쳤다. 충돌 도메인의 구성원은 서로 충돌에 연루될 수 있다. 충돌 도메인 외부에 있는 장치는 내부에 있는 장치와 충돌하지 않는다.
다중접속 방식은 충돌 도메인 내의 한 장치만 한 번에 전송할 수 있으며, 도메인의 다른 장치는 네트워크를 수신하고 다른 장치가 이미 전송 중일 때는 충돌을 피하기 위해 전송을 삼가도록 지시한다. 한 번에 한 장치만 전송할 수 있으므로 총 네트워크 대역폭은 충돌 도메인의 모든 장치 간에 공유된다. 충돌은 또한 충돌 도메인에서 네트워크 효율성을 저하시키는데, 충돌로 인해 장치가 전송을 중단하고 나중에 재전송해야 하기 때문이다.
데이터 비트는 유한한 속도로 전파되므로, 동시에라는 용어는 충돌 도메인의 크기와 허용되는 최소 패킷 크기로 정의되어야 한다. 패킷 크기가 작거나 차원이 크면 발신자가 메시지의 첫 번째 비트가 가장 먼 노드에 도달하기 전에 패킷 전송을 마칠 수 있다. 따라서 해당 노드도 이미 진행 중인 전송에 대한 단서 없이 첫 번째 패킷을 파괴하면서 전송을 시작할 수 있다. 충돌 도메인의 크기가 초기 발신자가 패킷을 보내는 시간 내에 두 번째 전송 시도(충돌)를 수신할 수 있도록 허용하지 않으면, 충돌을 감지하지 못하고 전송을 반복할 수 없다 – 이것을 지연 충돌이라고 한다.
공유 매체를 사용하는 이더넷에서 충돌은 경쟁하는 패킷이 버려지고 한 번에 하나씩 재전송되는 반송파 감지 다중 접속 및 충돌 탐지(CSMA/CD)를 사용하여 해결된다. 이것은 네트워크 비효율성의 원인이 된다.