> At 05:48 PM 2/7/02, Steven A. Ridder wrote: >>What I meant was that SYN in tcp is just a bit that's >>flipped to 1 to one. The bit is always there, but when it's >>turned "on" it means something. > > Yes. (So is it bit-oriented? I would say yes, even though > the term usually refers to WAN protocols) > >>I've >>never considered it data. > > IP considers it data.
There's lots of babbling about what belongs in what layer, but the underlying concept of layering is a sound one. A protocol at layer N considers everything it carries from the (N+1) layer above it as data. The protocol may have its own control messages, which do not carry _user_ data. > >> The get in http or open in ftp is data in the >>packet that has to be added to the packet. There is no "get >>flag" or "open flag" that needs to be turned on. It's a >>command, and when sent to an http server, the server >>responds. >> >>Am I right? > > Yes, it's a command. (Of course a TCP SYN is a command too > that a server responds to.) > > I would add that HTTP and FTP commands and replies are in an > HTTP or FTP header. (They aren't part of the actual "user" > data, and, in fact, FTP opens a different channel to send > the data.) > > FTP sends commands as strings (using the Telnet protocol). > There's no OPEN but there is, for example, a RETR. The > client software sends those actual characters in ASCII, > followed by a space or CR/LF and maybe an argument, > depending on the command. > > HTTP requests have a request line, with a method, optionally > a message header, and the message body. The method is the > command, like a GET. It is sent as a string, like the FTP > commands. SMTP and POP send string commands too. > > I asked about routing protocols too. They usually have a > header that includes a fixed-length "opcode" or "type" or > "command" field that identifies the purpose of the packet. > The protocol specifies the valid hex values for this field > and what command they represent. They aren't strings, > though. Actually, there is a substantial difference in the design assumptions for packet design in OSPF and ISIS. OSPF uses lots of bit strings and tries to 32-bit align as many fields as possible. The principal goal of this was processing efficiency. ISIS, however, had a different principal goal, extensibility. It's relatively easy to add type-length-value objects to ISIS. So there's more time in processing the packets, but you don't run into the problems of OSPF now that various bit fields are all used and there's no obvious place to extend them. OSPF extension tends to rely on creating whole new LSAs. > > And then Howard had yet more examples! I guess programmers > can be as creative as they want (despite numerous > technical, political, and historical constraints!) > > Priscilla Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=34808&t=34629 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
