12 skills found
nicolasbrailo / Cpp Exception Handling AbiA mini ABI capable of handling throw/catch statements for C++ without libstdc++
GPMueller / Mwe Cpp ExceptionMinimum working example of proper C++11 exception handling
kmalloc / SimpleCppExceptionHandlinga simplified version of c++ abi for exception handling
mehmetoguzderin / Vulkan Raytraced CubeRaytraced version of LunarG/VulkanSamples/../cube.cpp with exceptions, glfw, glm, stb and more C++14 features.
lolin32 / ESP32Arduino core for ESP32 WiFi chip Build Status Need help or have a question? Join the chat at https://gitter.im/espressif/arduino-esp32 Development Status Installation Instructions: Using Arduino IDE Windows Mac OS Debian/Ubuntu Decoding Exceptions Using PlatformIO Using as ESP-IDF component ESP32Dev Board PINMAP Development Status Most of the framework is implemented. Most noticable is the missing analogWrite. While analogWrite is on it's way, there are a few other options that you can use: 16 channels LEDC which is PWM 8 channels SigmaDelta which uses SigmaDelta modulation 2 channels DAC which gives real analog output Installation Instructions Using through Arduino IDE ###Instructions for Windows Instructions for Mac Install latest Arduino IDE from arduino.cc Open Terminal and execute the following command (copy->paste and hit enter): mkdir -p ~/Documents/Arduino/hardware/espressif && \ cd ~/Documents/Arduino/hardware/espressif && \ git clone https://github.com/espressif/arduino-esp32.git esp32 && \ cd esp32/tools/ && \ python get.py Restart Arduino IDE Instructions for Debian/Ubuntu Linux Install latest Arduino IDE from arduino.cc Open Terminal and execute the following command (copy->paste and hit enter): sudo usermod -a -G dialout $USER && \ sudo apt-get install git && \ wget https://bootstrap.pypa.io/get-pip.py && \ sudo python get-pip.py && \ sudo pip install pyserial && \ mkdir -p ~/Arduino/hardware/espressif && \ cd ~/Arduino/hardware/espressif && \ git clone https://github.com/espressif/arduino-esp32.git esp32 && \ cd esp32/tools/ && \ python get.py Restart Arduino IDE Decoding exceptions You can use EspExceptionDecoder to get meaningful call trace. Using PlatformIO PlatformIO is an open source ecosystem for IoT development with cross platform build system, library manager and full support for Espressif ESP32 development. It works on the popular host OS: Mac OS X, Windows, Linux 32/64, Linux ARM (like Raspberry Pi, BeagleBone, CubieBoard). What is PlatformIO? PlatformIO IDE Quick Start with PlatformIO IDE or PlatformIO Core Integration with Cloud and Standalone IDEs - Cloud9, Codeanywehre, Eclipse Che (Codenvy), Atom, CLion, Eclipse, Emacs, NetBeans, Qt Creator, Sublime Text, VIM and Visual Studio Project Examples Using "Stage" (Git) version of Arduino Core Building with make makeEspArduino is a generic makefile for any ESP8266/ESP32 Arduino project. Using make instead of the Arduino IDE makes it easier to do automated and production builds. Using as ESP-IDF component Download and install esp-idf Create blank idf project (from one of the examples) in the project folder, create a folder called components and clone this repository inside mkdir -p components && \ cd components && \ git clone https://github.com/espressif/arduino-esp32.git arduino && \ cd .. && \ make menuconfig make menuconfig has some Arduino options "Autostart Arduino setup and loop on boot" If you enable this options, your main.cpp should be formated like any other sketch //file: main.cpp #include "Arduino.h" void setup(){ Serial.begin(115200); } void loop(){ Serial.println("loop"); delay(1000); } Else you need to implement app_main() and call initArduino(); in it. Keep in mind that setup() and loop() will not be called in this case. If you plan to base your code on examples provided in esp-idf, please make sure move the app_main() function in main.cpp from the files in the example. //file: main.cpp #include "Arduino.h" extern "C" void app_main() { initArduino(); pinMode(4, OUTPUT); digitalWrite(4, HIGH); //do your own thing } "Disable mutex locks for HAL" If enabled, there will be no protection on the drivers from concurently accessing them from another thread/interrupt/core "Autoconnect WiFi on boot" If enabled, WiFi will start with the last known configuration Else it will wait for WiFi.begin make flash monitor will build, upload and open serial monitor to your board ESP32Dev Board PINMAP Pin Functions Hint Sometimes to program ESP32 via serial you must keep GPIO0 LOW during the programming process
jashwanth / Remote Code PublisherRemote-Code-Publisher Purpose: A Code Repository is a Program responsible for managing source code resources, e.g., files and documents. A fully developed Repository will support file persistance, managment of versions, and the acquisition and publication of source and document files. A Remote Repository adds the capability to access the Repository's functionality over a communication channel, e.g., interprocess communication, inter-network communication, and communication across the internet. In this project we will focus on the publication functionality of a Remote Repository. We will develop a remote code publisher, local client, and communication channel that supports client access to the publisher from any internet enabled processor. The communication channel will use sockets and support an HTTP like message structure. The channel will support: HTTP style request/response transactions One-way communication, allowing asynchronous messaging between any two endpoints that are capable of listening for connection requests and connecting to a remote listener. Transmission of byte streams that are set up with one or more negotiation messages followed by transmission of a stream of bytes of specified stream size2. The Remote Code Publisher will: Support publishing web pages that are small wrappers around C++ source code files, just as we did in Project #3. Accept source code text files, sent from a local client. Support building dependency relationships between code files saved in specific repository folders, based on the functionality you provided in Project #2 and used in Project #3. Support HTML file creation for all the files in a specified repository folder1, including linking information that displays dependency relationships, and supports and navigation based on dependency relationships. Delete stored files, as requested by a local client. Clients of the Remote Code Publisher will provide a Graphical User Interface (GUI) with means to: Upload one or more source code text files to the Remote Publisher, specifying a category with which those files are associated1. Display file categories, based on the directory structure supported by the Repository. Display all the files in any category. Display all of the files in any category that have no parents. Display the web page for any file in that file list by clicking within a GUI control. This implies that the client will download the appropriate webpages, scripts, and style sheets and display, by starting a browser with a file cited on the command line2. On starting, will download style sheet and JavaScript files from the Repository. Note that your client does not need to supply the functionality to display web pages. It simply starts a browser to do that. Browsers will accept a file name, which probably includes a relative path to display a web page from the local directory. You could also start IIS web server and provide an appropriate URL to the browser on startup. Either approach is acceptable. If you use IIS, you won't have to download files, but you are obligated to show that you can do that. Requirements: Your Remote Repository: (2) Shall use Visual Studio 2015 and its C++ Windows console projects, as provided in the ECS computer labs. You must also use Windows Presentation Foundation (WPF) to provide a required client Graphical User Interface (GUI). (1) Shall use the C++ standard library's streams for all console I/O and new and delete for all heap-based memory management. (3) Shall provide a Repository program that provides functionality to publish, as linked web pages, the contents of a set of C++ source code files. (4) Shall, for the publishing process, satisfy the requirements of CodePublisher developed in Project #3. (4) Shall provide a Client program that can upload files3, and view Repository contents, as described in the Purpose section, above. (3) Shall provide a message-passing communication system, based on Sockets, used to access the Repository's functionality from another process or machine. (2) The communication system shall provide support for passing HTTP style messages using either synchronous request/response or asynchronous one-way messaging. (1) The communication system shall also support sending and receiving streams of bytes6. Streams will be established with an initial exchange of messages. (5) Shall include an automated unit test suite that demonstrates you meet all the requirements of this project4 including the transmission of files. (5 point bonus) Shall optionally use a lazy download strategy, that, when presented with a name of a source code web page, will download that file and all the files it links to. This allows you to demonstrate your project using local webpages instead of downloading the entire contents of the Code Publisher for demonstration. (5 point bonus) Shall optionally have the publisher accept a path, on the commandline, to a virtual directory on the server. Then support browsing directly from the server by supplying a url to that path when you start a browser. This works only if you setup IIS on your machine and make the path a virtual directory. The TAs will do that on the grading machines. Categories are the names of folders in which the Repository stores its source code and web files. You may define Categories in any way that seems sensible. For example, they could simply be the namespace(s) for the uploaded files, or a Client supplied name. You will find a demonstration of how to programmatically start an application here. The stream capablity is intended to send files, which could be either text or binary format. Stream size will be the file size. Transmitting and receiving byte streams will be used to send and receive files in either text or binary format. This is in addition to the construction tests you include as part of every package you submit. Project 3 statement: Purpose: A Code Repository is a Program responsible for managing source code resources, e.g., files and documents. A fully developed Repository will support file persistance, managment of versions, and the acquisition and publication of source and document files. This project focuses on just the publishing functionality of a repository. In this project we will develop means to display source code files as web pages with embedded child links. Each link refers to a code file that the displayed code file depends on. There are several things you need to know in order to complete this project: Each file to be published is a C++ source file. Our publisher will generate, for each of these, an HTML file, with most of the contents drawn from the code file. The pages we will generate have only static content, with the exception of some embedded JavaScript and styling, so we won't need a web server. We will need to preserve the white space structure of the displayed source code. That can be done embedding all the code between the tags <pre> and </pre> or by using the CSS white-space property with value "pre" to style a div with all the code in its contents. Any markup characters in the code text will have to be escaped, e.g., replace < with < and > with >. File dependencies are displayed in the web page with embedded links, which are implemented in HTML5 with anchor elements: <a href="[url of referenced html page]">source code file name</a> For each class, we will, optionally, implement outlining, similar to the visual studio outlining feature. To do that we will use the CSS display property, with values: normal or none, to control whether the contents of a div are visible or not. The Code Publisher will be embedded in a mock Repository with almost no functionality except to support publishing of source code as web pages. Specifically you are not expected to provide support for: package checkin or checkout versioning You are expected to support: Dependency analysis of the C++ source code files you will publish, using the analyzer you developed in Project #2. The ability to specify, on the command line, files to be published, by providing command line arguments for path and file patterns. The ability to display any file cited on the command line, by starting a process that runs a browser of your choice, naming the specification of the file you want to display. Note that the CodePublisher project creates a code generator. Its inputs are C++ code and its outputs are HTML code. Requirements: Your CodePublisher Project: (1) Shall use Visual Studio 2015 and its C++ Windows console projects, as provided in the ECS computer labs. (2) Shall use the C++ standard library's streams for all console I/O and new and delete for all heap-based memory management1. (4) Shall provide a Publisher program that provides for creation of web pages each of which captures the content of a single C++ source code file, e.g., *.h or *.cpp. (10) Shall, optionally2 provide the facility to expand or collapse class bodies, methods, and global functions using JavaScript and CSS properties. (2) Shall provide a CSS style sheet that the Publisher uses to style its generated pages and (if you are implementing the previous optional requirement) a JavaScript file that provides functionality to hide and unhide sections of code for outlining, using mouse clicks. (2) Shall embed in each web page's <head> section links to the style sheet and JavaScript file. (4) Shall embedd HTML5 links to dependent files with a label, at the top of the web page. Publisher shall use functionality from your Project #2 to discover package dependencies within the published set of source files. (2) Shall develop command line processing to define the files to publish by specifying path and file patterns. (3) Shall demonstrate the CodePublisher functionality by publishing all the important packages in your Project #3. (5) Shall include an automated unit test suite that demonstrates you meet all the requirements of this project2. That means that you are not allowed to use any of the C language I/0, e.g., printf, scanf, etc, nor the C memory management, e.g., calloc, malloc, or free. This optional requirement will take a significant amount of work to complete successfully. You should get everything else working before attempting this additional effort. This is in addition to the construction tests you include as part of every package you submit.
LinkedInLearning / Mastering Cpp Exception Handling 3812077This repo is for Linkedin Learning course: Mastering C++: Exception Handling
PSPDFKit-labs / Cpp Exceptions TestingSome benchmark and bin size tests for blog post.
rkday / Cpp Exception InterposerInterposer to log a backtrace at the point where a C++ exception is thrown
GowthertG / CPP Module 05This module is designed to help you understand Try/Catch and Exceptions in CPP.
mhahnFr / CallstackLibraryLibrary creating human-readable call stacks.
dakotale-zz / Text Chat ApplicationCSE4/589: PA1 Description CSE 489/589 Programming Assignment 1 Text Chat Application 1. Objectives Develop the client and server components of a text chat application, consisting of one chat server and multiple chat clients over TCP connections. 2. Getting Started 2.1 Socket Programming Beej Socket Guide: http://beej.us/guide/bgnet 2.2 Install the PA1 template Read the document at https://goo.gl/L2kgb5 in full and install the template. You should complete this step before reading further. It is mandatory to use this template. 3. Implementation 3.1 Programming environment You will write C (or C++) code that compiles under the GCC (GNU Compiler Collection) environment. Furthermore, you should ensure that your code compiles and operates correctly on 5 dedicated hosts/machines, which will be provided to you by the instructor. Your code should successfully compile using the version of gcc (for C code) or g++ (for C++ code) found on the 5 dedicated hosts and should function correctly when executed. NOTE: You are NOT allowed to use any external (not present by default on the dedicated hosts) libraries for the socket programming part. Bundling of code (or part of it) from external libraries with your source will not be accepted either. You can however use external modules for other parts of the assignment (like maintaining a linked list). If you are not sure whether you are allowed to use an external library or not, consult with the course staff. Further, your implementation should NOT invoke any external binaries (e.g., ifconfig, nslookup, etc.) and should NOT involve any disk I/O unless explicitly mentioned in the PA description. 3.2 Sockets Use TCP Sockets only for your implementation. Use the select() system call only for handling multiple socket connections. Do not use multi-threading or fork-exec. 3.3 Running your program Your program will take 2 command line parameters: The first parameter (s/c) indicates whether your program instance should run as a server or a client. The second parameter (number) is the port number on which your process will listen for incoming connections. In the rest of the document, this port is referred to as the listening port. E.g., if your executable is named chat_app: To run as a server listening on port 4322 ./chat_app s 4322 To run as a client listening on port 4322 ./chat_app c 4322 3.4 Dedicated Hosts For the purpose of this assignment, you should only use (for development and/or testing) the directory created for you on each of the 5 dedicated hosts. Change the access permission to this directory so that only you are allowed to access the contents of the directory. This is to prevent others from getting access to your code. 4. Output Format We will use automated tests to grade this assignment. The grader, among other things, will also look at the output generated by your program. Towards this end, ALL the required output (as described in section 5) generated by your program needs to be written to BOTH stdout and to a specific logfile. Later sections provide the exact format strings to be used for output, which need to be strictly followed. 4.1 Print and LOG We have already provided a convenience function for this purpose in the template (see src/logger.c and include/logger.h), which writes both to stdout and to the logfile. You should use ONLY this function, for all output described in this assignment. On the other hand, if you want to output something more to stdout (for debugging etc.) than what is described, do NOT use this function and rather use native C/C++ function calls. Any extra output in the log file will cause the test cases to fail. To use the function, you will need to have the following statement at the top of your .c/.cpp source file(s) where you want to use this function: #include “../include/logger.h” The function is designed to behave almost exactly as printf. You can use the function as: cse4589_print_and_log(char* format, ...) Read the comments above the function definition contained in the src/logger.c file, for more information on the arguments and return value. 5. Detailed Description The chat application follows a typical client-server model, whereby we will have one server instance and two or more client instances. Given that we will be testing on the five dedicated hosts listed before, you can assume that at most four clients will be online at any given time. The clients, when launched, log in to the server, identify themselves, and obtain the list of other clients that are connected to the server. Clients can either send a unicast message to any one of the other clients or a broadcast a message to all the other clients. Note that the clients maintain an active connection only with the server and not with any other clients. Consequently, all messages exchanged between the clients must flow through the server. Clients never exchange messages directly with each other. The server exists to facilitate the exchange of messages between the clients. The server can exchange control messages with the clients. Among other things, it maintains a list of all clients that are connected to it, and their related information (IP address, port number, etc.). Further, the server stores/buffers any messages destined to clients that are not logged-in at the time of the receipt of the message at the server from the sender, to be delivered at a later time when the client logs in to the server. You do NOT need to buffer messages for EXITed clients or from BLOCKed clients (see section 5.6). You can assume that the total number of buffered messages will not exceed 100. Your code, when compiled, will produce a single executable file. Depending on what arguments are passed to this executable (see section 3.3), a client or a server instance should be started. 5.1 Network and SHELL Dual Functionality When launched (either as server or client), your application should work like a UNIX shell accepting specific commands (described below), in addition to performing network operations required for the chat application to work. You will need to use the select() system call which will allow you to provide a user interface and perform network functions at the same time (simultaneously). 5.2 SHELL Commands Your application should accept commands only when they are inputted: In UPPER CASE. Having exactly the same syntax as described below. 5.3. SHELL Command Output [IMPORTANT] The first line of output of all the commands should declare whether it was successfully executed or it failed. If the command was successful, use the following format string: (“[%s:SUCCESS]\n”, command_str) //where command_str is the command inputted without its arguments If the command failed with error, use the following format string: (“[%s:ERROR]\n”, command_str) //where command_str is the command inputted without its arguments For all such required output, you should only use the special print/log function described in section 4. See section 5.4 (IP command) for an example code snippet. If the command is successful, it should immediately be followed by its real output (if any) as described in the sections below. Extra output lines in the log file between the success message and output will cause test cases to fail. The last line of the output of all the commands (whether success or failure) should use the following format string: (“[%s:END]\n”, command_str) //where command_str is the command inputted without its arguments For events, printing format/requirements will be the same as for commands. Each of the event’s description tells the value of the command_str you should use for it. 5.4 Server/Client SHELL Command Description This set of commands should work irrespective of whether the application is started as a server or a client. AUTHOR Print a statement using the following format string: (“I, %s, have read and understood the course academic integrity policy.\n”, your_ubit_name) Your submission will not be graded if the AUTHOR command fails to work. IP Print the IP address of this process. Note that this should not be the localhost address (127.0.0.1), but the external IP address. Use the following format string: (“IP:%s\n”, ip_addr) //where ip_addr is a null-terminated char array storing IP Example Code Snippet To generate the required output for this command, you would need the following lines in your code: //Successful cse4589_print_and_log(“[%s:SUCCESS]\n”, command_str); cse4589_print_and_log(“IP:%s\n”, ip_addr); cse4589_print_and_log(“[%s:END]\n”, command_str); //Error cse4589_print_and_log(“[%s:ERROR]\n”, command_str); cse4589_print_and_log(“[%s:END]\n”, command_str); Here, command_str and ip_str are char arrays containing “IP” and some valid IP address like “xxx.xx.xx.xx”, respectively. Any extra output in between the SUCCESS/ERROR and END output will cause the test cases to fail. PORT Print the port number this process is listening on. Use the following format string: (“PORT:%d\n”, port) LIST Display a numbered list of all the currently logged-in clients. The output should display the hostname, IP address, and the listening port numbers, sorted by their listening port numbers, in increasing order. E.g., 1 stones.cse.buffalo.edu 128.205.36.46 4545 2 embankment.cse.buffalo.edu 128.205.36.35 5000 3 highgate.cse.buffalo.edu 128.205.36.33 5499 4 euston.cse.buffalo.edu 128.205.36.34 5701 Use the following format string: /*The following printf will print out one host. Repeat this printf statement to * print all hosts * list_id: integer item number * hostname: null-terminated char array containing fully qualified hostname * ip_addr: null-terminated char array storing IP * port_num: integer storing listening port num */ ("%-5d%-35s%-20s%-8d\n", list_id, hostname, ip_addr, port_num) Notes: LIST output should contain all the currently logged-in clients, including the client that executed the command. The server should NOT be included in the output. If you do not implement the LIST command correctly, most automated tests for other commands will fail. 5.5 Server SHELL Command/Event Description This set of commands should work only when the application is started as a server. STATISTICS Display a numbered list of all the clients that have ever logged-in to the server (but have never executed the EXIT command) and statistics about each one. The output should display the hostname, #messages-sent, #messages-received, and the current status: logged-in/logged-out depending on whether the client is currently logged-in or not, sorted by their listening port numbers, in increasing order. E.g., 1 stones.cse.buffalo.edu 4 0 logged-in 2 embankment.cse.buffalo.edu 3 67 logged-out 3 highgate.cse.buffalo.edu 7 14 logged-in 4 euston.cse.buffalo.edu 11 23 logged-in Use the following format string: /*The following printf will print out one host. Repeat this printf statement to * print all hosts * list_id: integer item number * hostname: null-terminated char array containing fully qualified hostname * num_msg_sent: integer number of messages sent by the client * num_msg_rcv: integer number of messages received by the client */ * status: null-terminated char array containing logged-in or logged-out ("%-5d%-35s%-8d%-8d%-8s\n", list_id, hostname, num_msg_sent, num_msg_rcv, status) BLOCKED <client-ip> Display a numbered list of all the clients (see BLOCK command in section 5.6) blocked by the client with ip address: <client-ip>. The output should display the hostname, IP address, and the listening port numbers, sorted by their listening port numbers, in increasing order. The output format should be identical to that of the LIST command. Exceptions to be handled Invalid IP address Valid but incorrect/non-existent IP address [EVENT]: Message Relayed All messages exchanged between clients pass through (are relayed by) the server. In the event of relay of a message <msg> from a client with ip address: <from-client-ip> addressed to another client with ip address: <to-client-ip>, print/log the message using the following format string: ("msg from:%s, to:%s\n[msg]:%s\n", from-client-ip, to-client-ip, msg) In case of a broadcast message, <to-client-ip> will be 255.255.255.255 For the purposes of printing/logging, use command_str: RELAYED 5.6 Client SHELL Command/Event Description This set of commands should work only when the application is started as a client. LOGIN <server-ip> <server-port> This command is used by a client to login to the server located at ip address: <server-ip> listening on port: <server-port>. The LOGIN command takes 2 arguments. The first argument is the IP address of the server and the second argument is the listening port of the server. On successful registration, the server responds with: 1. List of all currently logged-in clients. The client should store this list for later display and use. 2. All the stored/buffered messages for this client in the order they were received at the server. Each of these messages will trigger an [EVENT]: Message Received, described at the end of this section. A client should not accept any other command, except LOGIN, EXIT, IP, PORT, and AUTHOR, or receive packets, unless it is successfully logged-in to the server. Notes You should NOT print the list of clients received as part of the output of the LOGIN command. The LOGIN SUCCESS/ERROR message should be printed after all the event related output (triggered by the buffered messages). Exceptions to be handled Invalid IP address/port number (e.g., 127.abc is an invalid IP; 43f is an invalid port). You can assume that a valid IP/port will always be the actual IP/listening port of the server. REFRESH Get an updated list of currently logged-in clients from the server. SEND <client-ip> <msg> Send message: <msg> to client with ip address: <client-ip>. <msg> can have a maximum length of 256 bytes and will consist of valid ASCII characters. Exceptions to be handled Invalid IP address. Valid IP address which does not exist in the local copy of the list of logged-in clients (This list may be outdated. Do not update it as a result of this check). BROADCAST <msg> Send message: <msg> to all logged-in clients. <msg> can have a maximum length of 256 bytes and will consist of valid ASCII characters. This should be a server-assisted broadcast. The sending client should send only one message to the server, indicating it is a broadcast. The server then forwards/relays this message to all the currently logged-in clients and stores/buffers the message for the others. Notes The client that executes BROADCAST should not receive the same message back. BLOCK <client-ip> Block all incoming messages (unicast and broadcast) from the client with IP address: <client-ip>. The client implementation should notify the server about this blocking. The server should not relay or store/buffer any messages from a blocked sender destined for the blocking client. The blocked sender, however, will be unaware about this blocking and should execute the SEND command without any error. Exceptions to be handled Invalid IP address. Valid IP address which does not exist in the local copy of the list of logged-in clients (This list may be outdated. Do not update it as a result of this check). Client with IP address: <client-ip> is already blocked. UNBLOCK <client-ip> Unblock a previously blocked client with IP address: <client-ip>. The client implementation should notify the server about the unblocking. Exceptions to be handled Invalid IP address. Valid IP address which does not exist in the local copy of the list of logged-in clients (This list may be outdated. Do not update it as a result of this check). Client with IP address: <client-ip> is not blocked. LOGOUT Logout from the server. However, your application should not exit and continue to accept LOGIN, EXIT, IP, PORT, and AUTHOR commands. In general, on LOGOUT all state related to this client is maintained on both the client and the server. Notes LOGOUT does NOT reset the statistic counters (see STATISTICS command in section 5.5). LOGOUT does NOT unblock any clients blocked by this client. LOGOUT does NOT change the blocked/unblocked status of this client on the server. EXIT Logout from the server (if logged-in) and terminate the application with exit code 0. This should delete all the state for this client on the server. You can assume that an EXITed client will never start again. [EVENT]: Message Received In the event of receipt of a message <msg> from a client with ip address: <client-ip>, print/log the message using the following format string: ("msg from:%s\n[msg]:%s\n", client-ip, msg) Note that <client-ip> here is the IP address of the original sender, not of the relaying server. For the purposes of printing/logging, use command_str: RECEIVED 5.7 BONUS: Peer-to-peer (P2P) file transfer Implement additional functionality to allow clients to send/receive files. Here, however, the transfer will take place directly between two clients and will not involve the server. For this, your implementation should establish a TCP connection between the two clients involved in a file transfer. The implementation does not need to handle any broadcast file transfers. All transfers will take place between a pair of clients. To send a file <file> residing in the same folder as the executable to a client with ip address: <client-ip>, a client would execute the following command: SENDFILE <client-ip> <file> The receiving client should store the file in the same folder as the executable, with the same name. Your implementation should be able to transfer both text and binary files. You can assume the maximum file size to be 10 MB. 6. Grading and Submission The grading will be done using automated tests. Any deviation from the output format/syntax described in previous sections will cause the tests to fail. For a detailed breakup of points associated with each command/functions, see https://goo.gl/UAVWgY For packaging and submission, see the section Packaging and Submission in https://goo.gl/L2kgb5 Published by Google Drive–Report Abuse–Updated automatically every 5 minutes
