• 0

Bytes with TCP socket and bit manipulation


Question

I'm taking a computer communication summer class and this is our 2nd and last program project. The protocol for the assignment can be found here.

I've already done one project that involves a client and server connecting and playing a game of guess the number with strings being sent back and forth. For this project though we have to manipulate individual bits of bytes and send only bytes across the socket connection. How do you do this in Java? I haven't been able to find anything about forming bytes with particular bits and sending just bytes across the connection.

11 answers to this question

Recommended Posts

  • 0

I'm not sure what your project assignment is doing (I dont' have time to read it). But from my experience in Java, to read binary data you use InputStream or OutputStream to read and write binary data.

Here's an example:

Let's assume "sock" is your socket connection.

InputStream in = sock.getInputStream();
while (in.read() != -1)
{
     //do whatever you need to do with it
}

You can also look at sun's java api for more info (search for inputstream).

Hope this helps!

  • 0

I've read some of the things on the input and output streams and i'll be definitely be using them. My problem comes after I've received the bytes. I have to use certain control bytes as notifiers for things:

00000001- REQuest connection.

00000010 - CONnection Granted.

ssss0011 - FILe name packet (sequence number sss = 000).

ssss0100 - DATa Packet, where sss is the sequence number of the packet.

ssss0101 - Short Data Packet(SDP), where sss is the sequence number of the packet.

ssss0110 - ACKnowledgment packet, where sss is the sequence number of the packet expected next.

ssss 0111 - list request packet (sequence number sss = 000).

0000 1111 - TERmination (a simple two-way handshake).

After I've received the bytes I don't understand how to interpret the different bits of the bytes to know what I'm dealing with.

  • 0

You can AND them (note this is C-style code)

if(byte == 0x01) // REQuest connection
{
}
else if(byte == 0x02) // CONnection granted
{
}
else if(byte & 0x0F == 0x03) // FILe name packet
{
    sequence = (byte & 0xF0) >> 4;
}

  • 0

Thx for the info Andareed!

I've taken computer structures so I understand the idea of And'ing and Or'ing things but I don't quite understand the hex strings your using. Any extra tips on those? I tried google'ing some stuff but it didn't really help. Also, what exactly does the >> do.

Edit:

Since hex is 16 bits I'm guessing the first digit is the first 4 bits and when you check for 0x0F you're testing to see if the first 3 bits are all 1's to know it's a file packet and similarly for the others. The >> still confuses me though.

Edited by Little Moe
  • 0

I've run into another problem. When sending a packet with file information one of the bytes has to be a one-byte unsigned binary value. I've found a whole lot of stuff about doing unsigned bytes in Java by using ints and AND'ing stuff with 0x0FF but my I think my problem comes with actually sending the byte.

My teacher expects our clients and servers to run against his C clients and servers. He gave us an example exe of each and whenever I run my client against his it says "Number of char in file name should be between 1 and 124 - LEN field = 0" like it's not getting my byte at all. I'm thinking it's either the byte I'm using or something special in the OutputStream that might be messing up my byte? I know there is no difference between the bits of a signed or unsigned byte but something is going wrong. Does anyone have an example of sending a byte like he is asking or maybe if I'm thinking of this wrong.

  • 0

I ended up finishing the project. My biggest problem starting off was I was trying to send bytes individually by just writing the bytes one at a time. My teacher was expecting the bytes one right after another. I had to send a byte array for him to get everything in a packet that I wanted. Couldn't just test one byte at a time. Had to test things just by hardcoding byte array values to see what happened.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Raspberry Pi Imager 1.9.4 released bringing performance improvements, bug fixes and more by David Uzondu Raspberry Pi Imager 1.9.4 is now out, marking the first official release in its 1.9.x series. This application, for anyone new to it, is a tool from the Raspberry Pi Foundation. It first came out in March 2020. Its main job is to make getting an operating system onto a microSD card or USB drive for any Raspberry Pi computer super simple, even if you hate the command line. It handles downloading selected OS images and writing them correctly, cutting out several manual steps that used to trip people up, like finding the right image version or using complicated disk utility tools. This version brings solid user interface improvements for a smoother experience, involving internal tweaks that contribute to a more polished feel. Much work went into global accessibility, adding new Korean and Georgian translations. Updates also cover Chinese, German, Spanish, Italian, and many others. Naturally, a good number of bugs got squashed, including a fix for tricky long filename issues on Windows and an issue with the Escape key in the options popup. Changes specific to operating systems are also clear. Windows users get an installer using Inno Setup. Its program files, installer, and uninstaller are now signed for better Windows security. For macOS, .app file naming in .dmg packages is fixed, and building the software is more reliable. Linux users can now hide system drives from the destination list, a great way to prevent accidentally wiping your main computer drives. The Linux AppImage also disables Wayland support by default. The full list of changes is outlined below: Fixed minor errors in Simplified Chinese translation Updated translations for German, Catalan, Spanish, Slovak, Portuguese, Hebrew, Traditional Chinese, Italian, Korean, and Georgian Explicitly added --tree to lsblk to hide partitions from the top-level output CMake now displays the version as v1.9.1 Added support for quiet uninstallation on Windows Applied regex to match SSH public keys during OS customization Updated dependencies: libarchive (3.7.4 → 3.7.7 → 3.8.0) zlib (removed preconfigured header → updated to 1.4.1.1) cURL (8.8 → 8.11.0 → 8.13.0) nghttp2 (updated to 1.65.0) zstd (updated to 1.5.7) xz/liblzma (updated to 5.8.1) Windows-specific updates: Switched to Inno Setup for the installer Added code signing for binaries, installer, and uninstaller Enabled administrator privileges and NSIS removal support Fixed a bug causing incorrect saving of long filenames macOS-specific updates: Fixed .app naming in .dmg packages Improved build reliability and copyright Linux-specific updates: System drives are now hidden in destination popup Wayland support disabled in AppImage General UI/UX improvements: Fixed OptionsPopup not handling the Esc key Improved QML code structure, accessibility, and linting Made options popup modal Split main UI into component files Added a Style singleton and ImCloseButton component Internationalization (i18n): Made "Recommended" OS string translatable Made "gigabytes" translatable Packaging improvements: Custom AppImage build script with Qt detection Custom Qt build script with unprivileged mode Qt 6.9.0 included Dependencies migrated to FetchContent system Build system: CMake version bumped to 3.22 Various improvements and hardening applied Removed "Show password" checkbox in OS customization settings Reverted unneeded changes in long filename size calculation Internal refactoring and performance improvements in download and extract operations Added support for more archive formats via libarchive Lastly, it's worth noting that the system requirements have changed since version 1.9.0: macOS users will need version 11 or later; Windows users, Windows 10 or newer; Ubuntu users, version 22.04 or newer; and Debian users, Bookworm or later.
    • Ancient CD app makes 64-bit comeback to support Windows 11 and probably Windows 10 too by Sayan Sen Remember when CDs or compact discs were a thing? While technically, they still are, their popularity and usage have dropped immensely with the rise in other standards like USB, as the latter continues to evolve, getting faster and gaining more features. Recently, Microsoft enforced some mandatory requirements for USB Type-C so as to ensure a uniform and consistent experience for Windows 11 users. On the topic of Windows 11 and CDs, a CD ripping tool from the Windows 95/98 era, dubbed "CD2WAV32," is back again after 16 years (from the Windows 7 era). The utility has now been updated to work on Windows 11 version 24H2, which is pretty cool. This was not planned, says the author, as they simply wanted to test the app on their newly upgraded Windows 11 PC, but ended up going all the way to make it fully work on Windows 11. Their Windows 11 runs an AMD Ryzen 9600X, 64 GB RAM, and an Nvidia GT 1030 (miswritten as "GT1300"). The developer of the tool notes that they did not run thorough tests on Windows 10, but it works on their Atom-based PC, which is another relic, given how fast technology moves. The author writes (Google-translated from Japanese to English): "From now on, it will only support Windows 11 (24H2). The reason is that this is the only environment the author currently has. I haven't done anything particularly fancy, so I think it will work properly on Windows 10, but I can't guarantee it. All I have left is an ATOM machine that I bought a long time ago that also runs Windows 10, so I've seen that it works lightly on that, but I can't do a detailed test." Atom, for those wondering, was Intel's low-power CPU lineup that it decided to axe back in 2016. The story is similar to how Microsoft gave up on Windows Lumia, as Intel, too, abandoned its mobile chip ambitions once the likes of Qualcomm and MediaTek took over. In terms of the underlying changes, the utility has been compiled now on Delphi 12.1 Community Edition, which is used to make native Windows apps as well as ones for macOS, iOS, and Android. The recent update also brings a significant overhaul in terms of compatibility as well as UX/UI. File sizes and other such metadata are now handled using a 64-bit format instead of the prior 32-bit approach, eliminating overflow issues and ensuring large file and disk space values are displayed correctly. This change is necessary given that large storage volumes are quite common these days. Additionally, support for 16-bit code calling functions has been entirely removed as Windows 11 is 64-bit only; thus, features like MSCDEX and TwinVQ compression are gone. Meanwhile, the font has been changed from MSP Gothic 9pt to Meiryo 10pt, so readability should not be a problem even on 4K screens. In terms of audio file encoding support, it is said to work with MP3 as well as WMA. So, should you download and run it? Probably not, given that the UI is entirely Japanese, but it is still a fun project to look at.
    • Xbox has lots of games… and there all coming to Playstation!
    • Athena was the goddess of wisdom and war interesting choice
  • Recent Achievements

    • Week One Done
      jbatch earned a badge
      Week One Done
    • First Post
      Yianis earned a badge
      First Post
    • Rookie
      GTRoberts went up a rank
      Rookie
    • First Post
      James courage Tabla earned a badge
      First Post
    • Reacting Well
      James courage Tabla earned a badge
      Reacting Well
  • Popular Contributors

    1. 1
      +primortal
      397
    2. 2
      +FloatingFatMan
      177
    3. 3
      snowy owl
      170
    4. 4
      ATLien_0
      167
    5. 5
      Xenon
      134
  • Tell a friend

    Love Neowin? Tell a friend!