The connection to the channels is established in two main different ways, depending on the technology that the channel supports: Real-Time and iCal.
Channels like Booking.com, Expedia, Agoda etc.. support real-time connections (via API) while channels like Airbnb, HomeAway, Flipkey etc.. are based on the iCal/ICS technology. On this website you can find a description for the technology supported by each channel.

What are the main differences? First of all, channels supporting real-time connections via API will let you manage also the rates beside the availability and the bookings. The rates cannot be managed for channels working with iCal Sync URLs.

Real-time connections are based on API calls made by the central servers of e4jConnect upon requests sent by Vik Channel Manager. Every time there will be a modification to the availability, these channels will be immediately notified and the new availability will be reflected instantly. The same thing works for any update requests sent to adjust the rates or the restrictions.
The iCal/ICS Synchronization is based on the exchange of URLs that return the availability in ICS format. This is basically a file that contains the dates and some information for each booking.

New bookings coming from Real-Time channels will be downloaded and transmitted to the properties with a maximum delay of 3 minutes. The maximum delay for downloading the new bookings from an iCal/ICS channel goes up to 3 hours instead. Average sync time is of 1 hour in this case.
Also, when you connect the channel manager to a Real-Time channel, this will download all the new bookings that will come through after the connection date. For example, if you connect the channel manager today with Booking.com, you will start receiving the new bookings that will be generated after today. There could be some exceptions in this case, where you could request a download of the bookings received up to 30 days prior the connection date.
With the iCal/ICS technology instead, you exchange a Sync URL (a link) with the channel. The channel manager will periodically (and automatically) parse that URL to see if there are new bookings. The channel will do the same by periodically parsing the Sync URL that you gave them. However, e4jConnect cannot control how often the channel will download and import your availability as they do this operation independently. Your channel manager could not force a channel to download your availability calendar for maybe closing a room, storing a new booking or simply updating the availability. This is possible only with the channels supporting real-time connections via API where the channel manager transmits to the portal the new availability.
So basically this is the main difference between the two technologies. Real-time channels are informed by the channel manager of any modification to the availability. Channels working with iCal Sync URLs instead will download the new availability by themselves, at fixed intervals. It may be possible that you can force the download of the availability (sync) from your own account on the channel but this should obviously happen automatically, and it does.

Moreover, when you connect a Sync URL in the channel manager, our servers will download it at the very next loop-interval and all the bookings with a check-out date in the future, will be transmitted to your property, no matter when you received these bookings. Of course, if you have already closed the booked dates in VikBooking, the channel manager will not notify you the bookings that actually already exist.

Another important aspect of the "Real-Time" channels is the fact that everything is based on the OTA Booking ID (the ID of the reservation generated by the portal). All the new bookings coming from these channels, that have never been transmitted or stored before in/to the channel manager, will be parsed: if you already have a booking with the same OTA ID, then the channel manager will skip it. Otherwise, if you had manually closed or registered a booking from the page Calendar of VikBooking and these dates have no longer availability, if this booking gets downloaded and transmitted from the portal, the channel manager will raise an error notification saying that there is no longer availability for those dates. This would happen because the booking that you've manually created via VikBooking, did not have the OTA ID and so the channel manager considers it as a different booking. This is a rare case that could happen when you stop or re-activate the connection with a channel. You basically store the booking manually on your site and if the channel manager downloads this booking again from the portal, it would like a situation of overbooking.
This explains how everything is based on the IDs of the bookings coming from the portals. The same thing would happen for a cancellation or for a modification: imagine the situation where you have to manually register a booking in VikBooking (your website) that was received from a portal before establishing the connection with this channel - this booking will be saved on your website without the reference to the "OTA Booking ID". If this booking gets cancelled or modified by the customer on the portal, the channel manager will retrieve a booking modification/cancellation for a booking ID that actually does not exist on your site. An error notification will be raised in this case. Instead, if the original new booking was transmitted to your channel manager, any future cancellation or modification will come through correctly.
As explained above, in case of iCal channels, bookings for dates where there is no availability on your website with VikBooking, will be ignored as it's assumed that they were already transmitted and stored.