Showing posts with label Chat. Show all posts
Showing posts with label Chat. Show all posts

Friday, November 26, 2010

Java Chat



This is another find in my workspaces!

Featuring this time a simple text based chat, based on a self-developed protocol allowing server client communication.

Features
  • Simple text chat
  • Multithreaded Server
  • Singlethreaded Client
  • fully swing compatible
  • Status messages in chat window (disconnects, errors etc.)
  • Overview list with all connected clients
  • Possibility to private/ group chat
How it works

The first thing to do is to start the server. This is as easy as it sounds just clicking on the "Start" button and we can leave the server alone, handling itself all connections etc.


Next step is to initiate a Client connection to the server. This can be done by starting the Client Chat application. Here we just need to specify the server's IP Address and an appropriate nick name.


Now we can see that the main window is enabled and we can now start chatting by typing some words into the textfiled below this chat window. On the right side the chatter list appears showing only one entry, us. Let's now invitate more people to show all features!

Next persons will be Alice and Bobby:



Here we can see that "Bobby" successfully connected to the server and received a message from "Chris". Furthermore a private message was sent to him only readable of him from "Alice".

After "Bobby" connected "Alice" also joined the chat and received the message from "Chris". Then "Alice" sent a private message to "Bobby". This could be done by unchecking "Chris" from the chat overview list on the right side.




This picture shows the final result when the user "chris" disconnected after chatting with Alice and Bobby.

If you want to know more how the connection is handled then you should take a closer look at the ServerClientHandlerThread and the ClientConnectThread. The main rule plays the MessageObject which is used to determine the connected Clients and their behavior.


Download

Maven Project - with Source Code
chat.zip

Runnable Jars
Server: ChatServer.jar
Client: ChatClient.jar

Wednesday, October 13, 2010

Update: JMF Video Chat New Features



New Release of the video chat:


Added Features:
  • Fixed some bugs
  • Improved error handling
  • Added NAT Holepunch Capability (explained below)
  • Added HTTP Tunneling Capability (explained below)
It may be now possible to stream RTP video data over the internet if you either choose the method
NAT Holepunch or HTTP Tunneling.

The techniques worked in following situations:
  1. Direct connection from a host (me) to a virtual machine on the host and vice versa
  2. Software Firewalls enabled
  3. In case of NAT Holepunch, I ran the relay server on the host and used two virtual machines which communicated with each other
Short explanation of added features:

NAT Holepunch:

Participants:
  • A relay server with open udp ports
  • One computer behind a NAT
  • Another computer behind a NAT
How it works:

NAT: Network address translation
--> means ports are forwarded to the device behind it and vice versa from the device to other devices

Problem: A lot of NAT devices permit receiving UDP packets, but sending them.

That's why we can send packets to a server who can listen on all UDP ports and accept our request.

Principle:

At first the relay server is listening on a pre defined port for incoming udp packets.
Computer A tries to send a UDP packet to this server.
The packet contains information about connection details of the according peer Computer A would like to connect to later.



The relay server gets the packet and remembers the senders IP + UDP port and the packet content for later requests by Computer B.

Now Computer B sends a UDP packet to the relay server with connection details (e.g. IP) of his according peer, namely Computer A.

The relay server again gets this request and compares in his list of requests whether the new connection details from the packet match one from earlier saved requests.



If thats the case the server sends out to both peers each others connection details to the open ports earlier received of them.



Now Computer A sends UDP Packets on this open port to the direct peer on his open port and vice versa.

Now both can communicate.

HTTP Tunneling and HTTP Streaming

If you are behind a firewall your only way to communicate with the outer world is to use port 80, which is used for all http traffic (when you are browsing the internet).

In this case HTTP Tunneling comes into play.

Principle:

Short version:

We use HTTP to send the video stream to the other peer and vice versa. That means both parties have to have a listening webserver on port 80.

Long version:

Originally RTP Packets are sent via UDP as underlying protocoll. Due to the nature of firewalls blocking most traffic in general it is not possible to stream your UDP packets to another location.

The solution is to use the only free port (80). This opens another problem. In contrast to RTP HTTP works with TCP/IP as underlying protocoll. This means we have to deal with packet retransmission and therefore delays in the reception of the data.

HTTP Streaming

One solution would be to implement the common known HTTP Streaming. This works the way that you have split your stream in time equavilant segments and send these to a webserver, which serves these files.

Now the client connects to the webserver and reads one file after another.
Bad side of this method: It is not real time anymore. Due to the creation of the files the client has to wait at least the time the server needs to capture one segment and load it onto the webserver.

So what to do now?
Well, I tried to implement my own HTTP Streaming solution which roughly works like this:

  1. start capturing from the webcam
  2. while capturing read out the streaming bytes
  3. wait until a certain buffer is filled with video data
  4. now send this buffered data over http to the opponent webserver
  5. on this webserver we read out the received data and create UDP packets which are sent to the local RTP Receiver
  6. steps 1-5 on both sides

Result:
Depending on your webcam it will work!

Pictures:

Hosting peer: Left side --> received stream over HTTP Tunneling
Right side-->webcam not working ;-)

Virtual Machine Client peer: Right side: local webcam stream, left: no reception due to bad webcam of other peer




Download

VideoChat1.2.jar

Environment
JRE 1.6_U20 32 Bit

Windows XP 32 Bit
Windows 7 64 Bit