This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computing: Networking / Software Low‑importance This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing Low This article has been rated as Low-importance on the project's importance scale. This article is supported by Networking task force (assessed as Low-importance). This article is supported by WikiProject Software (assessed as Low-importance).

Is it true that in TCP/IP one partner is always a server and the other always a client? The only way I can see this being the case is that one machine must listen for a connection while the other initiates the communication - however once a TCP channel is up there's no client/server distinction inherent in the protocol. I'd suggest that this page only gets to make such a statement if AAPC *doesn't* work like that - ie if it doesn't have the notion of listening for a connection. However, I can't conceive of any other mechanism for doing networking. 195.212.29.83 (talk) 12:14, 25 April 2008 (UTC)[reply]

It’s not entirely unfair to say that TCP is client-server: one side requests the connection, the other provides it. It’s a little bit misleading because a TCP channel can be established and then used in any fashion at all, peer-to-peer or client-server or anything else you might invent, but the establishment of the channel is definitely client/server.

I changed the statement to say just that TCP is client-server, because TCP/IP is a protocol stack, and making that statement about a protocol stack is nonsense. IP is definitely peer-to-peer, there’s no asymmetry between hosts because there’s no established channel between communicating hosts. Ngriffeth (talk) 13:08, 11 August 2025 (UTC)[reply]

I do have a further question about it though: how are AAPC connections established? Could it be, like TCP, a client-server arrangement as I described in my previous reply? It’s hard to see how a connection can be established without one side requesting it first. I’m not familiar with SNA so don’t want to get into it, but perhaps someone that knows it could comment. Ngriffeth (talk) 13:14, 11 August 2025 (UTC)[reply]

The link is dead. --217.195.52.165 (talk) 19:21, 26 April 2008 (UTC)[reply]

Hello fellow Wikipedians,

I have just modified one external link on IBM Advanced Program-to-Program Communication. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20120212230623/http://www.redbooks.ibm.com/abstracts/GG244485.html?Open to http://www.redbooks.ibm.com/abstracts/GG244485.html?Open

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 00:41, 10 November 2017 (UTC)[reply]