home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.protocols.tcp-ip      TCP and IP network protocols.      14,669 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 13,062 of 14,669   
   Jorgen Grahn to Barry Margolin   
   Re: Looking for tutorial code - A TCP sy   
   22 Sep 09 15:59:27   
   
   XPost: comp.os.ms-windows.programmer.win32   
   From: grahn+nntp@snipabacken.se   
      
   ["Followup-To:" header set to comp.protocols.tcp-ip.]   
   On Mon, 21 Sep 2009 11:38:05 -0400, Barry Margolin  wrote:   
   > In article   
   > ,   
   >  Ramon F Herrera  wrote:   
   >   
   >> What I need is to:   
   >>   
   >>  - client creates a socket (TCP, sync)   
   >>  - server accepts   
   >>  - client sends some (say, 4) arguments   
   >>  - server reads them (I am stuck in this part now)   
   >>  - server does some processing (I have no problem with this)   
   >>  - server sends the results back   
   >>  - client reads them   
   >>   
   >> A perfect example was the Boost set of daytime (port 13) examples, BUT   
   >> they do not pass arguments.   
   >   
   > I think you need to do some googling on "marshaling" or "serializing".   
   > These are the terms used for representing sequences of values (either   
   > structured or individual parameters) in a serial form.   
      
   Here I'd like to mention plain text protocols, like HTTP, SMTP, IMAP   
   ... all the succesful application-level protocols really.   
      
   Much easier to debug, write test cases for, and document. Plus there   
   are lots of examples of successful designs in RFCs, and you can reuse   
   your experience from designing, reasoning about and writing parsers   
   for text file formats.   
      
   (I guess plaintext is marshaling/serializing too, but when I hear the   
   words I think of undocumented, non-portable heaps of bits, rather than   
   a well-designed single-purpose protocol.)   
      
   > Basically, you have to come up with an unambiguous way to represent your   
   > data, so that the client can write the parameters, the server can read   
   > them, and then the same thing can be done with the results the server   
   > sends back.   
   >   
   > Sun RPC uses XDR, eXternal Data Representation.   
      
   And there are libraries for it, ready for use. Yes, if he *needs* a   
   non-text encoding he should use something like that, not reinvent the   
   wheel (and get it wrong).   
      
   /Jorgen   
      
   --   
     // Jorgen Grahn    O  o   .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca