I understand the principle of collision domains and how they are issues in hubs. I also get how switches are actually creating its own collision domain on each port.
Therefore Port to Port communication creates a collision domain and takes care of collisions. It is all find and dandy here.
What about the situation when I have two switches — let's assume 48 ports each, daisy-chained together?
What will happen when 48 ports on switch1 will receive transmissions at the same time and need to resend it to 48 ports on switch2? I assume that all 48 signals should be transferred over the SINGLE daisy-chain link. Will that one link introduce ONE collision domain for all 48 ports? I logically assume that it won't, but I don't understand how.
Daisy-Chained Switches – How Collisions Are Handled
ethernetosiswitch
Related Solutions
This will be a bit of a layman's answer, rather than quoting spec, but it should be accurate.
The collision domain is the sum total of the network segment (hosts, hubs) affected by the collision, and forced to deal with it by a random backoff delay.
Anytime a collision is detected on an Ethernet line, any and all interfaces on that line are required to stop transmitting. They each then come up with a random amount of time to wait before transmitting again, in an attempt to avoid another collision. In a crowded network, this delay will start to add up very quickly, and the collision domain is essentially the sum total of equipment that delay affects.
As in your quote, it comes up a lot less these days. The original Ethernet gear that filled the role of the switch was a hub, which simply repeated any frame sent to it out all of the other ports. Once a network got even lightly congested, this made collisions a common symptom. Modern switch technology virtually eliminates that problem, since any frame received by the switch is only sent to the host it's intended for. The only possible collision is between a host and the switch, making it a very small collision domain, affecting only that host.
First a word about:
I understand word persistent as following : no one else can occupy wire at the time of persistent connection. So this connection is only one-to-one. But this is not right. Persistent connection can be established while other packets are going through the same wire.
This is circuit-switched network vs packet-switching network
circuit-switched network
In such networks, a physical dedicated line is established between the two hosts who wants to communicate.
The better example is the first phone networks where human operators manually connect two phone lines to establish communications on request.
Latter human operators where replaced with mechanisms. The enterprise internal version of such mechanism is known as "PBX" (Private Branch eXchange).
In this case you actually have a physical connection that is maintained and nobody else can use any of the circuit during that time.
packet-switching network
IP networks are packet-switched networks. As you said many packets from several applications can flow on the wire at the same time, and for a single conversation, different packets can take different routes.
This allow better utilization of the link and more robust design (of course it has some drawbacks).
So at the IP layer there's no "connection" nor "session" established.
There's an emerging trend to identify flows and apply specific switching and / or routing rules to them, and a flow can for example correspond to a TCP session but this is not what we usually refer to when speaking about connection / session.
Connection
IP provide two main protocols (among others) to establish communication between two hosts : UDP and TCP.
UDP is connection-less. That means (quoted from Wikipedia) that "a message can be sent from one end point to another without prior arrangement. The device at one end of the communication transmits data addressed to the other, without first ensuring that the recipient is available and ready to receive the data".
TCP is connection-oriented. Before actually transmitting date, the two hosts talk to each other to check that they are both available and agree to exchange some kind of data (think of the preamble of a typical phone call). This connection is maintained until one host signal that it want to end it or after some time has passed without exchanging any data.
A VPN connection usually work the same way. Two hosts exchange some information (including which encryption protocol to use, some cryptography keys and user authentication mechanism etc...) and if bot agree on the terms, a connection is established and maintain. Usually some keep-alive packets are sent at regular interval to say "I'm still here, don't drop the connection".
Session
Sessions are established by applications. A session can correspond to a single TCP connection, but a session can use several different TCP connection or use UDP as the transport protocol.
A HTTP(s) session for example may use cookies to identify the user and can provide access to different resources (think about web banking).
A Voice Over IP (VOIP) phone call will use the SIP protocol. SIP means "Session Initiation Protocol" and it can run over UDP.
The exact mechanism of establishing / maintaining / closing a session depends on the applications used.
Best Answer
If all 48 ports attempt to TX to the same "port" at the same time, it will most likely overrun the internal buffer space and "no buffer" (in cisco circles) drop the frame(s). As this is all at layer-2, no error is communicated to anyone; the frames just don't get there.
(This is all part of the store-and-forward processing of switches.)