ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
The peer node has to tell you it's address or IP name. The user should be able to get this information from his system. It may not be a fixed address, as many Internet Service Providers assign different IPs each time the node boots, or after some arbitrary time period. The node may have a fixed name, even in the absence of a fixed IP, and the user at that node should be able to find out that name. A dynamic DNS service may be of value for this. If you are using Linux, the easiest way it find the IP assigned to an interface is with ifconfig. If there is one or more firewalls between the connecting hosts, you may have to modify the firewall rules to accommodate your software, and your software may need to accommodate the firewall(s), by sending client requests to the firewall IP rather than the end host.
The type of messages sent through TCP connections or UDP datagrams is completely arbitrary. The communications layer knows only how to build & maintain connections, and transport data through the connections. It will be completely up to you and your software to figure out how to transfer files through that layer. In the case of TCP, the connection can be kept open for as long as required to perform the transfer(s). That is, in theory, at least. In practice, connections sometimes get broken, and your software will have to recognize this, and handle rebuilding the connection as appropriate. For a 10GB file transfer, you should expect this circumstance to arise. You will want your software to be able to resume a transfer after rebuilding a new connection. You don't want to restart a file transfer after 9.9GB of data have already been sent.
TCP &/or UDP is undoubtedly used for instant messaging.
Posting a long piece of code like that, not even in CODE tags so formatting is all over the map, and expecting someone to debug it by inspection is asking a lot. Why don't you break out the elements, like the file transfer parts, into separate, smaller functions, and test and debug those as individual pieces. Then you can focus on a smaller subset of the overall problem, and also modularize your code more. For testing, use input arguments from argc/argv or read from stdin. Most of the people who read your code will not understand the mixture of GTK GUI code (assuming that is what it is) and the relatively straightforward IP sockets components. Divide and conquer.
Create separate client side and server side stubs, and test & develop slowly, building on to what you get working as you you procede. For testing and developing networking code, I find tools like C-Kermit, telnet, ethereal/wireshark, and especially netcat indispensible. When developing a package that has two interoperable components, it is helpful to have one side of the equation that you can rely on to be fully functional. If the overall program doesn't work, it is difficult to test & debug one end with a peer component which itself may be buggy. The tools I mentioned may be already installed with your distro, but if not, are easily obtained online.
Having said that, nothing immediately jumps out at me as being clearly wrong, although the code is very difficult to read as-is. Some things I find a bit off-putting: too few comments, poor use of variable names, hardcoded IP names, unmodular architecture. Does it compile and link cleanly? When you run it, what does it do or not do?
Okay, you should break the socket level code out into separate functions, and create simple wrappers with main() functions that exercise the individual client and server components. Build these as standalone programs, and test & debug them. Use netcat as the peer, and see that connections are being properly created and that data is being transferred. Once these components are functional, move them back into your target application. Make most or all configurable items such as IP addresses, ports, filenames, and the like into function parameters, and start the stub application by passing them as commandline arguments, which your main() function will parse from argc/argv.
So you will start out with a simple server & simple client. Run them independently, giving runtime parameters such as IP, port, and payload like:
Code:
client 12.34.56.78 1234 "This is a string to send"
Once you see the 'string to send' arriving at the netcat server, move on to sending a file instead of a string. This is the sort of progression that will give you some success and learning experience. Once the client is working, do the same for the server side. Then move the working code back into your overall package.
I'm sorry I don't know much about GTK applications, except that most of what goes on as application-specific code happens as callback procedures, and this often makes it difficult to test non-trivial callback code. There may be issues regarding how much time can be spent in a callback, without disrupting the end-user interaction with the program, similar to the constraints usually applied to interrupt processing.
You should not expect anyone in this forum to download your code, build it, debug it and send you the working result. You will learn little or nothing from that, and by your actions, the only thing to be gained from this endeavor is the learning experience.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.