Thread: Socketing

Page 4 of 4 First ... 234
  • Jump to page:
    #46
  1. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,179
    Rep Power
    2222
    Originally Posted by miz6565
    Alright. That's an easy fix.

    Anything else you have to say about the programs before I read on a graceful shutdown?
    It'll be a day or two before I have time. I'm waiting for a visitor right now. Nothing except the strerror jumped out at me immediately. And the manner in which you're handling the sending and receiving of messages depends on what you're actually trying to do, which I would need to try to figure out which would take time. But off-hand I'm not seeing how the client's user can quit the program since I don't see any way except a networking error to get out of that loop.
  2. #47
  3. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2013
    Posts
    101
    Rep Power
    0
    And the manner in which you're handling the sending and receiving of messages depends on what you're actually trying to do, which I would need to try to figure out which would take time.
    Same thing as the TCP/IP server/client program, I'm just making an echo server where the client types up certain amount of words and the server outputs what the client inputted.

    But off-hand I'm not seeing how the client's user can quit the program since I don't see any way except a networking error to get out of that loop.
    As I said, I wasn't sure if I'm supposed to close the socket in a graceful shutdown since UDP is connectionless. Because of that, I thought since UDP is unreliable I, the client, can just exit whenever I want and it wouldn't matter. Guess I was wrong, wasn't I?

    And may I ask, I almost know the basics of UDP and TCP/IP, how to do a graceful shutdown and all that. The only thing I'm expected to learn next is how to handle multiple clients, but you say that's an advanced topic. Shall I get back to socket programming later on in life when I learn another language (or if one day I program in C and want to move on in Socket programming) or should I stick with it until I achieved all of socket programming?

    It's just that I have other things to do but if I'm close to the end or this is really going to help I'll stick with socket programming. It's been a month, I didn't think it would take this long to understand it.
  4. #48
  5. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,179
    Rep Power
    2222
    OK, the server enters the infinite loop (ie, while(1) ), clears the buffer and waits for a datagram. When it receives a datagram, it sends it right back to where it came from, then it clears the buffer and waits for another datagram. That is indeed basically how the server should behave. And you also have it terminating if there is an error in either receiving or sending. That's OK for now, but later you would want to create a more robust server that could look at the type of error it got and try to take action to correct it. That's covered under the general topic of exception handling, which is provided under C++, C#, and Java -- in C, you have to create your own mechanism.

    Now I look at the client. It enters the infinite loop, gets a string from the user, and sends it. Then it waits for a datagram from anybody (that's what recvfrom does) and when it gets something it prints out the data that was received. But then it loops back and waits for the user to enter another string to send.

    The only way to exit the client's infinite loop is for either sendto or recvfrom to fail. I have difficulty thinking of a way for that to happen. How do you intend for the user to exit the client? For example, I checked the string that the user types in to be sent and if it is an empty string (ie, all he did was hit Enter) then he would exit the loop. I see nothing remote like that in your program -- no exit command, no exit option, nothing but having to force the program to crash (eg, Ctrl-C).

    In the latter 1980's, I worked and the sole programming for a small company that designed computerized greenhouse controls. When I started, we ran a Turbo Pascal control program under MS-DOS on an IBM XT clone, but it originally ran on an Apple II, I think in BASIC. My boss was the company's nationally-recognized "computer expert". His way of exiting our control program was to reboot the computer, Ctrl-Alt-Del, AKA "the three-finger salute". No real computer expert would want to do it that way, in part because it would cause data to be lost from any files that are still open, but mainly because you just don't do it that way! You have written your client in such a way that the user has to resort to the "two-finger salute", hitting Ctrl-C.

    The concept of gracefully terminating a program is not limited to network programming, but rather to every single program that we write.

    BTW, did you test the server and the client against each other using the code that you posted? I couldn't help but notice that the client was trying to connect on port 7 while the server was listening on port 59023.

    Originally Posted by miz6565
    As I said, I wasn't sure if I'm supposed to close the socket in a graceful shutdown since UDP is connectionless. Because of that, I thought since UDP is unreliable I, the client, can just exit whenever I want and it wouldn't matter. Guess I was wrong, wasn't I?
    I hope you now understand that I wasn't talking about graceful shutdown with UDP, but rather the non-sockets aspect of the program allowing the user to exit the program gracefully.

    And, yes, basically with UDP the client can just simply stop sending when he's done. Unless the Application Level protocol requires that he sign out. For example, if you're transfering a file with TFTP, I believe that you need to end that session with the server before you exit your program, since if you don't then the server is stuck there waiting in mid-session. Or if you're using a chat program you'd need to sign off so that the other users can know that you're no longer signed on. UDP itself doesn't require it, but the appliction you're running might.

    Originally Posted by miz6565
    The only thing I'm expected to learn next is how to handle multiple clients, but you say that's an advanced topic. Shall I get back to socket programming later on in life when I learn another language (or if one day I program in C and want to move on in Socket programming) or should I stick with it until I achieved all of socket programming?
    I would say that you should stick with it, depending on your priorities. What I was advising was that you become more comfortable working with TCP and UDP before moving on to the multiple-client problem. For example, the non-blocking sockets solution requires that you check for a very specific error code, so if you're still weak with getting and working with error codes then you wouldn't be ready for that technique quite yet.

    Originally Posted by miz6565
    It's just that I have other things to do but if I'm close to the end or this is really going to help I'll stick with socket programming. It's been a month, I didn't think it would take this long to understand it.
    There's lots more to network programming, but you should have most of sockets programming by now. I'm saying that in the sense that sockets programming is about using the sockets functions and data structures to get data packets from one computer to another, while networking programming also involves making actual use of that data to do meaningful and fun things. It's kind of like disk file I/O: sockets programming is like learning the file I/O functions and how to write to different kinds of files and to read from them, while network programming is like all the possible application programs you could write that make use of file I/O.

    Whenever I've wanted to learn a new computer language or a new programming technology (eg, Windows GUIs, sockets programming), I would come up with a project to do that would use that language/tech. That way, not only would I be motivated to work on learning, but I would also be less likely to give up on something just because it got a little hard. Perhaps you would want to decide on a project that involves network programming, such as a qtod server ("quote of the day", which returns to you a quote or a joke that the server picks randomly whenever you call it) or a chat client/server (somewhat more ambitious). Or a game, especially one that involves multiple users (to play-test it, invite your friends to bring their laptops over for an old-fashioned LAN party, though you might not have to include the crimping bee to make the cables). The project would present you with practical problems to solve and hence specific questions to ask.

    But it depends on what your plans are.

    BTW, in UNIX/Linux programming, you often will have created multiple processes that need to communicate with each other. One method of inter-process communication (IPC) are UNIX sockets, basically what you've been learning to do, only without IP addressing.

    I'm way past the end of my lunch hour now. Gotta get back to work.
  6. #49
  7. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2013
    Posts
    101
    Rep Power
    0
    Ok. I fixed that problem on the UDP client. I made it so if you don't type anything and just press enter, client stops talking to the server.

    BTW, did you test the server and the client against each other using the code that you posted? I couldn't help but notice that the client was trying to connect on port 7 while the server was listening on port 59023.
    No..no. I first made the client program test with your server program. When it worked I posted it here and then I ran it with my server program.

    There's lots more to network programming, but you should have most of sockets programming by now.
    Ahh, first let me say one thing. Hearing the words I understand most of socket programming made my day.

    Anyway, I do feel 100% comfortable with TCP/IP and UDP now. Learning it was a joy, and testing with it was even more fun!

    Socket programming is a subset of network programming. I must know what else is to network programming? Are you able to give me details? Whenever I try to look up network programming all I get is socket programming.

    I just need the deeds of network programming. I probably will take a break as of a fact just learning socket programming took a while, but I don't know. From how socket programming was exciting I couldn't imagine what the next step is like.

    So please, can you give me a behind the scenes look on network programming ;)
  8. #50
  9. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,179
    Rep Power
    2222
    Originally Posted by miz6565
    Ahh, first let me say one thing. Hearing the words I understand most of socket programming made my day.
    Well, more accurate you've got most of the mechanics. Understanding TCP/IP is also important. And I mean understanding to the point were you're practically able to think in it almost like thinking in a foreign language instead of having to figure everything out, which is also a goal in programming. That part takes practice and working with it. Perhaps one test would be review my presentations of TCP/IP to see what sense it makes.


    Originally Posted by miz6565
    Socket programming is a subset of network programming. I must know what else is to network programming?
    Application Layer protocols. That's the really interesting stuff; sockets just enables you to do it.

    You tried to start with HTTP, so maybe you would want to go back to learn more about it. There's the O'Reilly book, O'Reilly - HTTP - The Definitive Guide, that you can download for free as a PDF.

    Or as I suggested, you might have a little project of your own. Like a game or a chat server or a database server (eg, send the server some information to store in a file, then come back later to retrieve or change that information).

    The thing is that application layer protocols usually require you to run a session, where the client "logs in" and sends a number of different commands to the server and the server responds with status and/or data messages. This would require you to define what those different messages would need to be (ie, message types, how they're formatted), what kinds of responses are required for what kinds of messages, and basically just exactly how a session would need to be conducted. And what the server and client are supposed to do when something doesn't work or something unexpected happens.

    Whatever you choose, try to make it something that interests, because I can guarantee that you will get frustrated very often while trying to implement it.

    For example, a few decades ago I had bought a modern naval miniatures game, Harpoon, designed by a Navy Reserve officer, Larry Bond. A friend and I played a simple 20-minute engagement between a US destroyer and three Soviet missile boats (OSA IIIs). Having plot everything out by hand took us a few hours, so my long-term project was to automate most of the mechanics. Of course, every time a new language or technology came along I'd start to redo everything. On top of that, full-time work and raising a family took a lot of my free time. That kind of networking project would be interesting, such that each object (each ship, aircraft, missile, torpedo) could each be a client of the server that would track and coordinate everything. Professional computer wargames use a similar approach (eg, Distributed Interactive Simulation (DIS)).

    Anyway, you have really just scratched the surface. So play with it to gain experience and learn new questions.

    And BTW, Larry Bond's Harpoon spawned a few generations of computer games as it passed from one company to another. And early on his pencil-and-paper game caught the attention of an aspiring author, Tom Clancy, who teamed up with Bond, using his game to play-test the battle scenes in The Hunt for Red October. They did a little co-writing and Bond has written a number of his own novels while working as a consultant.
  10. #51
  11. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2013
    Posts
    101
    Rep Power
    0
    Hmm, alright. I think I'm going to lay off network programming for a little while. Sockets was fun and all but like I said, I have other things I wanted to learn over the summer.

    But I just want to say thank you for helping me answer my questions. You were a real help.

    Later on, I'll get back to network programming. Probably during my middle high school year.

    As I told you, when I looked up more information on network programming on the internet all the sites just dealt with socket programming, not the application layer part. So when I get back, to you recommend me using this book?
    http://beej.us/guide/bgnet/
    Is that a reliable book?
  12. #52
  13. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,179
    Rep Power
    2222
    Beej's Guide has been around for quite a while and is recommended often. I even read it when I was starting out. However, he concentrates on UNIX programming (some of his examples use fork) and only mentions Winsock in one place. But, as I've also said, you can still use most of what he writes under Winsock too.

    You might also want to book-mark two other sites:

    1. The Winsock Programmer's FAQ at http://tangentsoft.net/wskfaq/.
    This is the FAQ for the alt.winsock.programming and comp.os.ms-windows.programmer.tools.winsock newsgroups. It serves as a repository of Winsock programming information and links.

    2. The UNIX Socket FAQ at http://developerweb.net/viewforum.php?id=70
    Almost more of a newsgroup than a FAQ. Users post their questions and other users try to help them.

    If your studies lead you to other programming languages, most of them also support sockets so you can still use what you've learned. One difference you'll encounter in object-oriented languages (eg, Java, C#) is that they will have encapsulated the detailed work inside of their class libraries. That last sentence will make more sense when you've learned an object-oriented language -- C++ would be a good next step after C, since it's mainly an extended C.

    And as you learn other things, that might give you ideas that you would want to use network programming for.
Page 4 of 4 First ... 234
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo