Applications assume bilateral connections?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Title: Applications assume bilateral connections?

One of the topics that came up in the architectural debate is that a few folk made statements of the form that application developers assume that applications only engage in bilateral communications. In fact one person went so far that applications developers are not aware of the range of applications protocols.

But more generally, some appear to have voiced the opinion that the IETF transport area only serves the IETF applications area, not the Internet application developer community which is many, many times the size of the IETF.

No examples were given of these non-application application protocols. So here is why there can only be bilateral communications at the application layer.


>From the point of view of an application there are only two significant classes of object:

1) Itself
2) Anything that is not itself

Every communication at the application layer, in every protocol that I am aware of boils down to a bilateral communication between those two groups. There are thus four possibilities

1) Application talking to itself, not as unusual as it might seem. I was once surprised to find that a DEC tape drive would not work unless RPC was turned on despite having a direct SCSI connection to the machine.

2) Inbound communication

3) Outbound communication

4) Communication that does not involve the application directly but may affect the application indirectly.


As far as an application is concerned, multicast is simply a communication with a service that is not itself. There may be one or a million hosts in a multicast session but the session itself is a single service. It is like being in an IRC chat room, there is one chat room, but many hosts.

If multicast protocols appear to require applications to have direct knowledge of an IP address, that is a layer violation. From my own point of view I am really skeptical about any protocol that requires state to be maintained in the Internet backbone to operate (as opposed to local state for optimization)

As it is however, the multicast protocols don't seem to be any different here. As far as the receivers are concerned they might as well be the only receiver in the entire world. As far as the source is concerned there is only the source and 'rest of world'.

Similar arguments may be applied to local broadcast.


_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]