The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

designing a new protocol

the usual TCP protocol accepts the first packet from the sender and then sends an ack, thus follows the three way handshake. i need to modify these steps.

wat i need to design is as follows :

when the first packet is received from an IP address i need to send an applet or somethin similar, to that IP address and based on the reply from that IP address will i establish a connection.

i can't figure out how i design this protocol, which programming language to use ( have a vague idea that i need to use kernel programmin..but believe me..its VERY vague!!)

it'll mean alot to me if someone out there who knows the answer to this helps me out.......

u could mail me at darkiceberg@gmail.com...
debjit ghosh Send private email
Monday, January 08, 2007
 
 
How are you going to send the applet to the client, if the TCP connection is not already established?

How are you going to get your extended version of TCP running on the client in the first place?

If you must design a new protocol, design it on top of TCP.  You don't gain anything by extending TCP.
DAH
Monday, January 08, 2007
 
 
The handshakes are there for a reason. You don't have a connection at that point. Just setup a normal connection and do the send after.
son of parnas
Monday, January 08, 2007
 
 
Sounds like the OP is trying to implement an ip adress spoofing protocol...
*myName Send private email
Monday, January 08, 2007
 
 
If building on TCP is not an option, I'd recommend building on UDP.  That way you don't have to mess with anything in the kernel.

But like noted above, sending an applet is probably something that should happen over TCP, so I'd rethink what you need to do.
Jason Send private email
Monday, January 08, 2007
 
 
What are you doing that can't be done on top of TCP?  That's an extremely unusual requirement.  I suspect you've misinterprted what people usually mean by "custom protocol" -- most custom protocols sit on top of either TCP or UDP, and govern what data is sent when, rather than how data is sent.
Angstroem
Monday, January 08, 2007
 
 
Why does it matter on how the data is transfered? TCP and UDP has been doing that great and handshakes are there for very good reasons.
What i don't understand is why you urgently need to push the applet out to the client before the handshakes? The only thing I can think of is spoofing like the other guy mentioned.
Simon Jia Send private email
Monday, January 08, 2007
 
 
You might also need to share which OS you are using before responders can give reliable suggestions for programming language selections.

If it's windows, there is a great VCL library available from
http://www.overbyte.be/frame_index.html (look for ICS) - it contains source for TCP and UDP (and other) protocols, with plenty of examples and an active mailing list.

The controls can be compiled using Delphi or Borland C++, and provide non-blocking, event driven access to common internet protocols. I've used them, they are great.

HTH
Aaron
Aaron DC Send private email
Monday, January 08, 2007
 
 
Actually, the three-way TCP connection establishment handshake is:

A ->  SYN -> B

B -> SYN/ACK -> A

A -> ACK -> B

Unless, one is trying to avoid SYN floods, one should build the authentication protocol on top of TCP.  Here is an example of a one-way authentication challenge protocol (this example assumes that a TCP connection has already been made and the two machine can exchange data via TCP):

B -> AUTHENTICATE -> A
A -> AUTHENTICATION_RESPONSE -> B

If the machine requesting a connection (“A”) cannot pass the authentication challenge or a “time-out” threshold is reached, the listener (“B”) just closes the TCP connection.
Mark V.
Thursday, January 11, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz