What does it mean for two components to be connected?
Let's note that the notion of a live connection between components in two computers, is really just some state held in each computer, that allows protocols to be followed to send bits to each other having desirable intentions and effects.
However, from an architectural point of view regarding two connected components:
In order to understand the connection between components, subsystems, services, client-server, or plain old objects, look to the specific approach used by one component to refer to the other.
The direction of the reference between components gives us the notion of dependency: the referrer is dependent upon the referee.
There are many approaches for reference, some result in tighter coupling than others.
In general, a direct reference uses the name of the other component, as in a line of code doing
new XYZ() for objects, or, the direct use of a well-known URL for services, and, such a direct dependency is a tightly coupled connection.
A somewhat more loosely coupled dependency uses an intermediate, though still directly named, such as a factory class for objects, or service locator for services.
Even looser coupling still is the injection approach where a parameter that was supplied during instantiation (or invocation) refers to an abstract capability rather than a directly named component (e.g. interface for objects or abstract service for services). Typically such components are seen to have a dependency on an abstraction rather than on another (concrete) component. The actual dependencies between concrete components are configured externally to the connected components.
Another aspect of connection is mutual dependency, where one component is directly dependent upon another and vice versa (i.e. the latter is directly dependent upon the former); this is often considered bad form as it leads to ordering issues and problems in instantiation and tear down. (In order to avoid cyclic dependencies, one or both components can use an approach of looser coupling, though this can be a difficult refactoring if such technical debt has been accruing for long.)
Additionally, how does the view of a connection differ from an software architecture perspective and an implementation perspective?
Architectural points of view often abstract out certain details in order to reason about some particular aspect of the system. For example, we might speak of a hard coded URL in one component referring to another component. This description ignores the DNS lookup that provides a level of indirection.
Another way they might differ is: Let's say an implementation uses an injection oriented approach, and that it is a data driven approach to configuration, where the data is supplied in a configuration file. Such an approach allows for changes between versions of the software, though for any given version, we might take an architectural point of view of the system that ignores the reconfigure-ability and looks at the interactions of components we know will be configured a certain way in this version.
My current understanding of the concept of "connection" is that two components (or entire systems) have some agreement with each other to exchange data across some interface. This is usually accomplished through initial request from one part, a subsequent process of handshaking, synchronization and eventually some communication session.
The handshaking & eventual transfer of data you're describing can be thought of as protocol, and applies to services, though in some sense can also be applied to objects and their APIs where certain things have to happen before others. Also relevant are the terms contract and abstraction, in addition to interface. These are various terms used to describe those prearranged agreements to exchange information using interfaces. These things happen and can be described many levels, e.g. wire protocols: TCP, REST APIs (the meaning of a single GET or POST vs. the collection and formation of query strings), document schemas for query results, etc...
Still, key to the notion of connection between components is the approach to how one component initially locates and identifies another component, as this is the essential element of the formation of connection from an architectural point of view, which goes to the above discussion on dependency and coupling, e.g. direct naming vs. service locator, vs. injection, or other, and from the implementation point of view, these connections and types of connections are manifest in specific ways.