Page 1 of 2 12 Last
  • Jump to page:
    #1
  1. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2012
    Posts
    54
    Rep Power
    3

    A simple game over the network


    can someone explain to me how i would implement a simple hangman over tcp? (client / server)

    i have a working hangman game

    i just don't know how to start programming it for network play
  2. #2
  3. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    What is it that you don't know? How to decide what data to pass between server and clients? How to restructure your program? How to write networking code?

    If the question is how to write networking code, here are a couple places to get started:
    Beej's Guide
    DWise1's Sockets Programming Pages

    It's called sockets programming. The next question is what operating system you're doing this on. Sockets were invented for UNIX and later adapted to Windows as Winsock. Beej's Guide is pure UNIX with only passing mention of what he guesses about Winsock, but I devote an entire page to Winsock (yeah, that second link is mine). As it turns out, Winsock supports most sockets code, but there are a few differences that you need to know; my page covers those differences.

    Also, my site includes some same programs, including examples of clients and servers for the echo protocol.
  4. #3
  5. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2009
    Posts
    149
    Rep Power
    36
    If you're doing this for Linux/Unix here are some useful links
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2012
    Posts
    54
    Rep Power
    3
    i have the simple client and server code

    where once i start the server it does nothing
    and wait for the client to connect

    whatever the client send the server jsut respond back with what the client sent


    but how do i modify this to work with the hangman game?/
  8. #5
  9. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2012
    Posts
    54
    Rep Power
    3
    how can i send a char instead of a string if that is possible?

    how can i make it that if the user enter an ip they r the client
    if they dont the become the server

    and wait for another instance of the program to start

    if i am making sense
  10. #6
  11. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2009
    Posts
    149
    Rep Power
    36
    Originally Posted by lucki_87
    how can i send a char instead of a string if that is possible?
    You could just send a string of length 1, which is pretty much the same thing as what you're asking for.

    how can i make it that if the user enter an ip they r the client
    if they dont the become the server
    I'm not sure what you're asking here. Could you be a bit more specific with an example of what you're talking about in the context of your hangman game?

    It is pretty much impossible to offer any further help with this since you have yet to show your hangman code. I'm not sure if your confusion is with your client/server design or if you don't know how to connect a client and a server.

    I recommend a thorough read of the 2nd link in the list of links I linked you to.
  12. #7
  13. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    Originally Posted by lucki87
    whatever the client send the server jsut respond back with what the client sent
    If you're talking about the sample programs on my site, then those are for the echo protocol. What you describe is what the echo protocol does. You can read RFC 862 for everything there is to know about the echo protocol.

    The purpose of those same programs are to provide working examples of how to create servers and clients and get them to connect and pass data. The actual protocol you implement with that code as a starting point is up to you.

    BTW, my page on client/server goes through what happens in a session, if you need more explanation.

    Originally Posted by lucki87
    but how do i modify this to work with the hangman game?/
    Well, just what exactly do you want the server to do for the client? Then when you've figured that out, you can develop the conversation that the client and server are to have with each other.

    But until you can tell us that, we cannot offer any help outside of basic "getting them to connect" type questions. It's your game. What do you want it to do?

    Originally Posted by lucki87
    how can i send a char instead of a string if that is possible?
    Actually, you're sending neither, but rather you send a packet. That packet can be any size (well, in tcp at least; udp datagrams are a different matter) and be formatted in any manner you choose; my page on data representation with packets, plus data insertion and extraction methods, gives you much more information on that question.

    If you choose for a packet to only contain a single character, then do it! You are in complete control of what you place into the buffer and on its length, both of which you pass to send(). Just be sure to write the server so that it will know that's the size of packet to expect.

    Originally Posted by lucki87
    how can i make it that if the user enter an ip they r the client
    if they dont the become the server
    Well, normally we write client and server programs separately, but they could be combined into the same program. Though mainly the end result would be a program with two unrelated parts, only one of which will be called by main() depending on the arguments on the command line. Frankly, I'd develop them as two separate programs at first and then lump them together.

    Originally Posted by lucki87
    and wait for another instance of the program to start
    Not sure what you're meaning there.

    The server needs to start up first, because the first thing that the client is going to try to do is to connect to the server. And the server is designed to sit there and listen on its listening socket for a client to connect to it, so what you might be asking is already taken care of.

    If you're talking about having multiple clients connect to the server, then realize that you need to:
    1. maintain separate client sockets for each of the clients that connect, and
    2. handle blocking sockets, so that the server won't freeze waiting to hear from one client and ignore all others.

    Obviously, my sample programs and the echo protocol are simple enough that they don't need to worry about blocking sockets, but as soon as you add a second client then you do need to worry about it. If you need to, then read my page on blocking sockets and how to deal with them.
  14. #8
  15. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    A few thoughts that might help you clarify what you're trying to do.

    There are three entities at work here: the server, the client, and the user. The server knows what the word is and the user doesn't, but the client could go either way. How much you want to let the client know will determine a lot about the design.

    The client could also know what the word is, but not tell the user. In that situation, almost all the server would need to do would be to give the client the word and leave it up to the client to run that entire round of the game, possibly reporting the results back to the server to be stored in a file (if that's a feature you want).

    Or the client could not know what the word is, in which case it would have to tell the server what each guess is and the server will then have to respond telling the client whether the guess is right and, if right, which positions in the word that letter goes.

    And what features you want to support will also determine a lot about the design. Do you want the user's results to be saved? If so, then each user will need to be able to "log in" and to "log out", as well as to ask to see his results, to start a new game, to resume an old game that had been interrupted, etc. That will create several different kinds of packets, each of which needs to be identifiable. You could use a set of commands or codes to identify the type of packet; you could examine the command sets of other protocols, such as HTTP and FTP, for ideas.

    Even if you don't get that fancy, if you have the server run the game (ie, you send it your guesses and it responds) then you will still have different formats for the responses from the server (ie, guess was right or wrong, what letter positions do that letter go to, user has lost or won the game) and different kinds of packets from the client (ie, here's the next guess, user has lost or won, user wants to play again, user is done playing and is disconnecting).

    The sockets part is easy. Connecting to the server and sending and receiving packets is easy and boringly standard, since you pretty much do it the same way with every networking program. The application protocol is the harder, more fun part. That's what you need to create, the application protocol for how the client and server will interact to accomplish the playing of your game. That is what you need to figure out.
    All we can do at this point is to bounce a few ideas around.

    PS

    In trying to work out the application-level protocol, start out by not even trying to think about how to format it. Just use your native language to list what the client and server need to tell each other, then organize that list in order of who needs to tell or ask of the other what and when. That will develop into a conversation between the client and server that will be what you can then implement in code.

    As tempting as it can be to immediately start coding, you need to first work out the design with pencil and paper so that when you do start coding you will know what you are trying to do.
    Last edited by dwise1_aol; November 27th, 2012 at 02:48 PM.
  16. #9
  17. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2012
    Posts
    54
    Rep Power
    3
    Or the client could not know what the word is, in which case it would have to tell the server what each guess is and the server will then have to respond telling the client whether the guess is right and, if right, which positions in the word that letter goes.
    how would i start to implement that?

    when the server send multiple string

    is there a way for the client to receive it separately?
  18. #10
  19. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    Originally Posted by lucki_87
    how would i start to implement that?
    Like I already told you:
    Originally Posted by dwise1_aol
    Just use your native language to list what the client and server need to tell each other, then organize that list in order of who needs to tell or ask of the other what and when. That will develop into a conversation between the client and server that will be what you can then implement in code.
    Figure out what the client has to tell the server and what the server has to tell the client. Everything, like:

    How does the server know to start a new game? The client needs some way to tell the server that.

    How does the client know how many spaces to display (ie, how long is the word)? The server needs some way to tell the server that.

    Those are two packets that would be needed.

    The client will send your guess to the server. There's a third packet. The server will tell you whether the guess is right or wrong and, if right, which positions the right guess will fill. A fourth packet.

    These are the kinds of questions that you need to ask yourself. Including, how does the receiving host know what kind of packet it just received? Maybe assign a number to each type of packet and insert that into the first byte of each packet?

    In other words, you need to create the protocol that the client and server will use. Once you have created that protocol, then formatting the packets and the rest should be easy.

    Create the protocol!

    Originally Posted by lucki_87
    when the server send multiple string

    is there a way for the client to receive it separately?
    Not completely sure what you're asking. You can send multiple strings. And you can either send them in the same packet or in separate packets, either way. That's trivial. If you send multiple strings in a single packet, then just devise a way to mark where one ends and the other begins; eg, use a NUL ('\0') just like C does.

    But first decide what the protocol should be, then worry about the details of implementing it.
  20. #11
  21. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2012
    Posts
    54
    Rep Power
    3
    so i try to code the game but running into some problems

    server once started:
    1) enter a secret word
    2) send this blanked out secret word for player to guess
    3) wait for the client to send a guess
    4) if the guess is correct
    send the word back with the character revealed
    else
    send a msg saying it is wrong
    5) if the player guess it right he wins become the server
    else another game is started

    client once started
    1) received the blanked word
    2) send a guess
    3) if the guess is right received the blanked word with the letter revealed in the correct position
    else
    a hangman part is drawn


    my question is
    when i put this in a loop i keep on getting the same msg multiple times

    if there a way to differentiate
    the packet sent is the word, or correctChoice or wrongChoice?
  22. #12
  23. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    How are you differentiating the different kinds of packets from one another? More specifically, when the server or client receives a packet, how do they know what kind of packet they had just received? It could be based on the order in which packets are sent/received, or it could be based on something inherent in each packet. What scheme are you using?

    There's a common complaint among the helpers on this forum, though I think I'm the only one who voices it in this manner: we are not mind-readers. All we know about your program and your code is what you tell us or show us. Quite frankly, you have been keep us very much in the dark about what you are doing.

    Originally Posted by lucki_87
    my question is
    when i put this in a loop i keep on getting the same msg multiple times
    We have two parties in this party: the client and the server. I assume that you are speaking here from the client's perspective. Since I'm using the word "assume", that means that I am guessing, which means that I could be guessing wrong. Your job as the "helpee" is to keep me, the helper, from having to make guesses which would very likely prove wrong. It is in your own interest as the "helpee" to help the helper help you. The way for you to help the helper is to provide us with all the pertinent information.

    Originally Posted by lucki_87
    if there a way to differentiate
    the packet sent is the word, or correctChoice or wrongChoice?
    Yes, there is, and I've been telling you about it all along. Since that has not gotten through to you, I'll try another approach.

    There are a legion of Internet/Web protocols. Have you ever asked yourself where they are all defined? They are all defined in a body of documents called "Request for Comment" (RFC), starting with RFC 1 on 7 April 1969. But instead of being requests for comments, they are actually public declarations of "this is what we have done and here is how it has been implemented." There are now several thousands of RFCs. Many of the earlier ones have been superceded (AKA "obseleted") by later ones, but that information is to be found in each RFC's header; for example:
    Code:
    Network Working Group                                         K. Sollins
    Request For Comments: 1350                                           MIT
    STD: 33                                                        July 1992
    Obsoletes: RFC 783
    
                         THE TFTP PROTOCOL (REVISION 2)
    From that header, you see that this deals with the "Trivial File Transfer Protocol" (TFTP), that it is RFC 1350, and that it obsoletes RFC 783. Similarly, in RFC 783's header, you will see information that it has been obsoleted by RFC 1350.

    Now, how do you find out which RFC(s) deals with the protocol you're interested in? You could look at the entire list of several thousands of RFCs, find one that mentions your protocol in its title, and then follow the chain of "Obsoleted by"'s. Or you could look that protocol up in Wikipedia, which will refer you to the pertinent RFCs.

    The reason why I'm pointing you to the RFCs is because you're trying to re-invent the wheel. Why re-invent the wheel? Research how others have done the same/similar thing and learn from their work. That's called "research" and learning to do research is really what you're supposed to be learning in college, AKA "learning how to learn". Of course, researching somebody else's work and trying to pass it off as your own work is called "plagiarism" and will get you expelled from school. So remember to always provide a bibliography and make all the appropriate attributions.

    Google on RFC 1350. That will point you to several copies of RFC 1350, the TFTP protocol. When you are viewing that RFC, scroll down to Section "5. TFTP Packets". With the TFTP protocol, you will request to download a file from the TFTP server ("Read request", or RRQ), upload a file to the TFTP server ("Write request", or WRQ), transfer a packet of data ("Data", or DATA), acknowledge receipt of a packet ("Acknowledgment", or ACK), or report an error ("Error", ERROR). That makes five different kinds of packets. How does TFTP differentiate between them? Here is an abridged copy of Section 5 (it is severely abridged, so read the original):
    Code:
    5. TFTP Packets
    
       TFTP supports five types of packets, all of which have been mentioned
       above:
    
              opcode  operation
                1     Read request (RRQ)
                2     Write request (WRQ)
                3     Data (DATA)
                4     Acknowledgment (ACK)
                5     Error (ERROR)
    
       The TFTP header of a packet contains the  opcode  associated  with
       that packet.
    
                2 bytes     string    1 byte     string   1 byte
                ------------------------------------------------
               | Opcode |  Filename  |   0  |    Mode    |   0  |
                ------------------------------------------------
    
                           Figure 5-1: RRQ/WRQ packet
    
    
                       2 bytes     2 bytes      n bytes
                       ----------------------------------
                      | Opcode |   Block #  |   Data     |
                       ----------------------------------
    
                            Figure 5-2: DATA packet
    
    
                             2 bytes     2 bytes
                             ---------------------
                            | Opcode |   Block #  |
                             ---------------------
    
                             Figure 5-3: ACK packet
    
    
    
                   2 bytes     2 bytes      string    1 byte
                   -----------------------------------------
                  | Opcode |  ErrorCode |   ErrMsg   |   0  |
                   -----------------------------------------
    
                            Figure 5-4: ERROR packet
    Notice that the format of each of the five types of packet is different, depending on the type of packet. Notice also that the very first field in the packet is the "opcode", a unique number that uniquely identifies what type of packet this is. TFTP uses two bytes, but it could just as easily be a single byte, since a single byte allows for 256 different "opcodes", ranging from 0 to 255.

    Now then, looking at how TFTP had done it. Do you see how you could differentiate the different kinds of packets so that when either the server or client would receive one, they would immediately know exactly what they had just received and how to handle it?

    Of course, keep in mind that TFTP is a UDP protocol, which is a "send and forget" protocol, so the ACK should be taken care of by your using TCP, but all the other ideas are still the same.

    Also, you should probably reference RFC 1350 as a source, to show that you had done some research. Teachers love it when a student shows that kind of initiative.

    Comments on this post

    • salem agrees : well said
    • MrFujin agrees
  24. #13
  25. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2012
    Posts
    54
    Rep Power
    3
    i understand what you are saying

    but how do i create such packet!

    for example

    let say

    packet 1:
    char word[24] = "1theword";

    send(socket, word, sizeof(word),0);

    the client received

    receive = recv(socket, buffer, sizeof(buffer), 0);
    buffer[receive] = 0;

    if (buffer[0] = '1'){
    printf("%s", buffer);
    this print 1theword

    i just want it to print theword
    }

    how can i do that?
    Last edited by lucki_87; December 1st, 2012 at 05:59 PM.
  26. #14
  27. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    Originally Posted by lucki_87
    i understand what you are saying

    but how do i create such packet!
    Oh, for frak's sake!

    How much C do you know? This is an honest and necessary question, because the members of this forum have a wide variety of C programming experience, in particular years of experience which ranges from decades of professional experience down to students who are just starting to learn. All experienced programmers (eg, I learned C and C++ circa 1990, after a decade of experience with Pascal (2 years in school and 8 professionally), such that most of my C/C++ experience has and continues to be through professional experience) were themselves once beginners and hopefully we all keep that in mind when dealing with beginners as we often do on this forum. So in that spirit I am asking you how much experience you've had.

    Network programming is generally considered a more advanced programming subject, even though it's really not that difficult. For someone to be attempting network programming, we normally expect them to be very conversant in C and to have learned several programming techniques and concepts. The impression I'm getting from your messages here is that you have not yet learned those programming techniques and concepts that we would normally assume.

    Earlier, I had pointed you to my web page, Formatting Packet Data (HINT: that is a link to the page). Did you read it? Did you understand it? Do you have questions about it? Why didn't you ask those questions?

    Since one of the work-related projects I had worked on was related to Network Time Protocol (NTP), I had written my own utility, UDPTimeC, which worked with the packet format defined in RFC 2030; I also included a time server with source code. Since the packet format specified in RFC 2030 was such a good example and I already had sample code for it, I used that as an example in my Formatting Packet Data web page. As I have said here before, it includes code examples for inserting and extracting data into and out of the packet's data buffer. My next question to you would be why you have chosen to ignore pertinent information that you needed. I will now keep myself from expressing how I feel about our precious free time being wasted thus.

    Please review my quoting from RFC 2030 as to the specification for the format of the data packet. Note also that it contains several fields some of which contain binary data. You cannot express binary data in a C-style string! And because some bytes of binary data could very easily contain zero, you cannot use the strlen() function or sizeof function to get the data buffer length. Every single field in that data packet has an offset from the start of the buffer, which is what you need to work with! My web page, plus the sample UDPTimeC and UDPTimeD programs, gives you a working example how to set up a data packet format and how to insert data into that packet and how to extract data from it. I do not see any reason to waste bandwidth by repeating all that here.

    Instead, I'll waste bandwidth by talking about the structure of the packets in TFTP, RFC 1350. Again, here's the greatly abridged quote from that RFC (meaning that you really should read the original):
    Code:
    5. TFTP Packets
    
       TFTP supports five types of packets, all of which have been mentioned
       above:
    
              opcode  operation
                1     Read request (RRQ)
                2     Write request (WRQ)
                3     Data (DATA)
                4     Acknowledgment (ACK)
                5     Error (ERROR)
    
       The TFTP header of a packet contains the  opcode  associated  with
       that packet.
    
                2 bytes     string    1 byte     string   1 byte
                ------------------------------------------------
               | Opcode |  Filename  |   0  |    Mode    |   0  |
                ------------------------------------------------
    
                           Figure 5-1: RRQ/WRQ packet
    
    
                       2 bytes     2 bytes      n bytes
                       ----------------------------------
                      | Opcode |   Block #  |   Data     |
                       ----------------------------------
    
                            Figure 5-2: DATA packet
    
    
                             2 bytes     2 bytes
                             ---------------------
                            | Opcode |   Block #  |
                             ---------------------
    
                             Figure 5-3: ACK packet
    
    
    
                   2 bytes     2 bytes      string    1 byte
                   -----------------------------------------
                  | Opcode |  ErrorCode |   ErrMsg   |   0  |
                   -----------------------------------------
    
                            Figure 5-4: ERROR packet
    OK, let's look at the formats of those individual packets. But first, look at what you're working with.

    First! I'm going to be talking a lot about bytes. There is not such datatype in C. Please substitute unsigned char for "byte" in the following and in any code that you write.

    All the data buffer of a packet is is bytes. A couple decades ago in the USA, there was a fast-food commercial for a competitor of McDonald's. McDonald's had a chicken sandwich made out of flaked pieces of chicken meat glued back together into a patty with fat -- a variant of Hormel's SPAM -- ; we referred to it as the "McCluck" or the "ChickenBurger". This competitor's chicken sandwich used a whole fillet of chicken meat, which they were trying to capitalize upon in their commercials. So in the commercial, a manufacturer for McDonalds (never actually named as such, of course) described what went into that flaked and reformed meat patty: "Bits." "But which bits of the chicken?" "Bits! Bits is bits." But in the consumer's eye, not all bits of a chicken are the same.

    The thing is that in computers, that is the exact truth of the matter. Bytes is bytes. There is absolutely nothing special about any individual byte. A byte is a byte is a byte. Bytes is bytes. Bits is bits. All that is different is how the software chooses to interpret those bits and bytes. And who chooses how the software interprets all those bits and bytes? You do, the programmer!

    Look at those two sockets functions: send() and recv(). What does the one send and the other receive? A string of bytes. What kind of bytes? Who cares? Bytes is bytes! What really matters is that the programmer specifies the packet format and then the sender and the receiver both know exactly which bytes to treat in exactly the right manner. But send() and recv() themselves do not care one fetid dingo's kidney how that data packet is formatted; all they ever care is where it is and how long it is.

    So then, all that really matters is what you do to that data buffer before you give it to send(). And that the receiving end knows to handle that data buffer in the exact same way that it had been handled before being sent. And, since you had stuffed that packet, you know how big it is.

    Now let's look at TFTP's packets and how they are formatted:
    Code:
                2 bytes     string    1 byte     string   1 byte
                ------------------------------------------------
               | Opcode |  Filename  |   0  |    Mode    |   0  |
                ------------------------------------------------
    
                           Figure 5-1: RRQ/WRQ packet
    The first field, Opcode, is at Offset 0, since it is the first field. It is two bytes long, so you will need to extract two bytes to get the Opcode. The problem here is that multi-byte data within packets are in network byte order; read my web page for the explanation! That means that, unlike Intel's [url=http://en.wikipedia.org/wiki/Little-endian]little-endian[/i] byte order, the data must be big-endian, meaning that the first byte you read is is the most-significant byte (MSB, which can also mean "most-significant bit", but only if you're dealing with a single computer word).

    The filename starts at the second byte of the packet; let's call that buffer[2]. It ends exactly the same as a C-style string, with a byte of zero (AKA '\0'). The thing is that the filename's length is variable, so by placing a zero byte, '\0', in the buffer right after the filename, you've marked the end of that field. Now all the receiving end needs to know is that in this type of packet (as indicated by the value in the Opcode field), the filename starts at buffer[2] and ends when a '\0' is found. But then another string follows, but your receiving program knows to keep track of where the filename's '\0' is, so that it knows that the following byte contains the starting character for the Mode, also terminated in standard C fashion, by a '\0'. Really quite simple, isn't it?

    Code:
                       2 bytes     2 bytes      n bytes
                       ----------------------------------
                      | Opcode |   Block #  |   Data     |
                       ----------------------------------
    
                            Figure 5-2: DATA packet
    Here again, the two bytes starting at buffer[0] tells you what kind of packet it is. Now let's read most of the rest of the RFC's description for this packet:
    Code:
       Data is actually transferred in DATA packets depicted in Figure 5-2.
       DATA packets (opcode = 3) have a block number and data field.  The
       block numbers on data packets begin with one and increase by one for
       each new block of data.  This restriction allows the program to use a
       single number to discriminate between new packets and duplicates.
       The data field is from zero to 512 bytes long.  If it is 512 bytes
       long, the block is not the last block of data; if it is from zero to
       511 bytes long, it signals the end of the transfer.  (See the section
       on Normal Termination for details.)
    Next, the ACK packets:
    Code:
                             2 bytes     2 bytes
                             ---------------------
                            | Opcode |   Block #  |
                             ---------------------
    
                             Figure 5-3: ACK packet
    While TCP guarantees delivery, UDP is "send and forget." TFTP uses UDP, but to guarantee delivery of the data packets, the protocol includes the receiving end sending an ACK packet to let the sending end know that a particular packet had been received.

    Again, the Opcode is two bytes long, network byte order, and the block number, also two bytes long, is at buffer[2].

    Code:
                   2 bytes     2 bytes      string    1 byte
                   -----------------------------------------
                  | Opcode |  ErrorCode |   ErrMsg   |   0  |
                   -----------------------------------------
    
                            Figure 5-4: ERROR packet
    Yet again, Opcode is at buffer[0], Errorcode is at buffer[2], ErrMsg is at buffer[4], and, since ErrMsg is of variable length, its null-terminator is at a variable offset, but at buffer_length - 1.


    And that is far more than you should need to be told if you are at all familiar enough with C as you should be to be tackling this kind of problem.


    Now to address the rest of your post:

    Originally Posted by lucki_87
    for example

    let say

    packet 1:
    char word[24] = "1theword";

    send(socket, word, sizeof(word),0);
    Absolutely not the way to format a data packet.

    First, define the buffer; the actual length can be greater that you might think:

    Code:
    typedef BYTE unsigned char;
    
    BYTE  buffer[256];
    Now, what is your format for the packets? I told you to define that. Have you?

    I will assume that you defined the packets to all start with a single byte, which is the "opcode" at buffer[0], the packet-type identifier. That means that in each and every packet, the actual data will always start at buffer[1].

    Furthermore, I assume that "opcode 1" refers to the packet that contains the word that is to be guessed.

    But what is it? Is it a value of 1, or a value of '1' (which is actually a value of 49)? Those are two very different values, so you need to specify which it is! In your very poor "code example", you are using the value of 49. In the TFTP protocol, they would be using the value of 1. You need to be extremely specific here.

    At this point, I am at a total loss. I know what your code was trying to say (I think), but is that what you meant? Without an actual specification of your protocol, I am totally confused.

    I did very explicitly tell you to define your protocol! Have you done that? It most certainly does not appear so!

    What is your protocol?!?!?!

    Without that extremely basic and fundamental information, I cannot possibly help you nor make any sense of any code that you may post.

    What is your protocol?
  28. #15
  29. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2012
    Posts
    54
    Rep Power
    3
    Isn't TCP/IP the protocol I specified?

    my c programming skill is 4 months

    my assignment is suppose to be a simple one but with all this packets and protocols talks i am more confused then ever

    would be be better if i post the client and server code up?
Page 1 of 2 12 Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo